03 / 笔记 · NOTES
这里不放教程，也不放读后感。每条只写三件事：我现在的判断、为什么这么判断、这条判断在什么条件下不成立。目前 9 条，按时间倒序。
AI 把实现压得很快之后，瓶颈上移到了需求定义。一份能被机器读的需求——一份 PRD，或者一个能跑起来的 demo——是唯一还能约束产出的东西。上游角色没有跟着升级，下游又舍不得拆掉自己赖以生存的旧流程，于是转型看起来像「工具不够」。
脚手架原本是为了补人的并行、处理、理解与记忆能力。AI 时代可以拆掉，前提是把需求聊清楚。难的地方不在技术，在这三件：底子（有没有自动化测试的习惯）、意愿与安全感（改动会打断别人的工作）、制度与资源（审批与管控限制了影响力）。
我最初的判断是「公司必须 AI 原生」，后来自己改成了「能转，但对底子、意愿、制度的要求都很高」。后者更准确。
边界 / LIMIT只在底子够、有人愿意改流程、制度给绿灯的组织里成立。三样缺一样，AI 只会让返工更快。
业务规则没有被显式写出来，需求就会变复杂；需求复杂，开发只能定制；定制越深，每次系统升级都要重构，而没有人能完整复现上一版代码。
换一个平台也一样。同一段没说清的逻辑会被重新加工一遍，所谓迁移，常常是把旧系统在新平台上再长一次。所以我判断一个数据或 AI 项目，先看业务规则有没有被写成可检查的东西，再看技术方案。
边界 / LIMIT这条不含对任何人的动机判断，只讲结构。规则写得清、口径统一的地方，定制化程度自然就低。
2026 年 9 月出过一次线上白屏：导航正常、内容区空着，构建和部署都是成功的。浏览器里真实的渲染，才是产品事实。
所以我现在对完成度的定义是：代码 + 构建 + 部署 + 浏览器冒烟 + 视觉验收。缺最后两步，就不能说完成；也不能把「部署成功」当成验收成功。
边界 / LIMIT纯静态、无路由无状态的页面可以只看构建；只要涉及路由、资源加载或交互状态，就必须从真实入口走一遍，包括嵌套路径。
提示词里写「请不要删除数据」，只是行为建议，不保证执行。真正挡住的，是工具白名单、只读账号、SQL 校验、返回行数上限、超时与重复调用检测这些结构。
顺序、权限、验证与恢复路径，必须由程序化的流程固定下来，而不是依赖某一次对话里的口头约束。这就是我把实现交给编码代理之后，仍然自己守着的部分。
边界 / LIMIT只读场景可以先把边界挡在外面；一旦要写入，权限与人工审批必须一起设计，单靠工具白名单不够。
系统知道多少、后台逻辑多复杂，不构成页面应该展示多少的理由。与当前决策无关的真实细节，也是认知负担。
技术 workflow 和 Agent 结构，要翻译成业务问题、约束、取舍和后果。解释的目标不是解释模型，而是让人分清四件事：哪些是数据事实、哪些是业务假设、哪些需要人来确认、哪些是可以执行的影响。
边界 / LIMIT影响因果理解的后台逻辑不能藏。颗粒度要跟着对方的决策、学习阶段与时间尺度走，不能一套密度打所有人。
同一个项目里三档编排我都跑过：固定管线的第一版、ReAct 循环的第二版、固定顺序执行的第三版。最稳的那一档，从来不是最像 Agent 的那一档。
Agent 的代价是具体的：超时、重复调用、跨轮状态丢失、并发占用。只有当输入形态每天都在变、需要多轮澄清和工具自选时，这些代价才值得付。先只读、后写入，写入要人批。
边界 / LIMIT这条不反对 Agent，它只要求先证明固定流程做不到，再升级。把 Agent 当默认选项的项目，通常还没想清要解决什么。
用知识库学习时，答案的准确度来自「把 canonical 条目读进上下文、只引用原文」，不来自模型的记性。
所以模型可以换更快更便宜的，代价只是追问变浅、跨条目综合变弱，而不是事实答错。需要深综合的问题，单独慢想一次。
边界 / LIMIT只对已经写成条目的知识成立。库外的问题必须承认在库外，不能用模型记忆补课。
个人 RAG 项目里，向量索引与全文索引差了 547 条，原因没查明；50 题 QA 有 18 题没过，一部分根因是数据质量。
这些我都留着当待办，不写成「已完成」。它能证明的是系统设计、测试与根因分析；不能声称的是完整的企业级生产 RAG 经验。
边界 / LIMIT内部复盘可以带未闭环数字，那是工作方法；对外只讲能追到出处的那部分。这条对我自己的站点同样适用。
想给十年后的自己留一条能边走边用的技能线：先决定想在哪儿生活，再让工作跟过去。判断顺序是会不会限制我去哪、二十年后需求还在不在、第一次真实验证要花多少钱、不干了学的东西还有没有用。
所以第一轮验证压在几百块的量级，专项和昂贵证照全部后置——除非前置的市场已经验证过。
边界 / LIMIT这是第二职业的筛选逻辑，不是现在就要转行，也不适用于主业。主业仍然要深度和连续性，不能靠「多试几个方向」来解决。