上个月我让 AI 改一个接口，改得挺好：一层校验、异常统一包装、顺手补了两个边界用例。

过了一周，我让它照着同样的思路改另一个模块。它换了一套写法：校验散在三个地方，异常直接往上抛，之前说好的封装它提都没提。

最气人的是，我去翻聊天记录，发现它当时"答应"过。

很多人把这种情况叫左右脑互搏——今天的 AI 在否定昨天的 AI。听起来像模型不稳定，但我后来发现，问题不在它的记性，在我们把什么当成了"准"。

今天的 AI 否定昨天的 AI，其实不是它健忘

先说结论：这类跑偏有三个原因，一个比一个更靠近根子。

第一是注意力的天然衰减。执行阶段高度依赖规划阶段的记忆，但上下文越聊越长，注意力就会被稀释，漏看一个关键决定，执行就整段走歪。

第二是决策丢失。会话一关，当时的技术取舍就跟着没了。下次新建窗口，AI 拿不到背景，只能凭当前代码猜你当初为什么这么设计。

第三个最容易被忽略：缺乏统一的底线规则。没有一条稳定的参考标准，它就很容易随意发挥，写着写着风格散架。

第三条才是关键。前两条是模型的客观限制，第三条是我们自己没做的事。

为什么聊得越久，它越容易跑歪？

因为聊天记录是一份"走马灯"式的记忆。

它记录的不是「以什么为准」，而是「发生过什么」。聊十轮下来，前面确立的规则被后面大量细节淹没，AI 再读到某段代码时，手上没有一份"必须遵守"的清单，只能在场的东西里挑最像的那个。

这种跑偏还有个特点：它往往不是立刻崩掉，而是一点点偏。你回头对一下才发现，接口规范变了、命名风格换了、错误处理方式前后不一致。

等到你要改，已经牵扯一片了。

这种稀释还有个具体表现：你明明在前几轮说过「这个接口不能改返回结构」，聊到第三十轮，它读到代码时先看的是当前实现，而不是先想起你立的约束。约束没被推翻，只是被淹没了。

分水岭是「以什么为准」

规范驱动开发（SDD）解决的就是这个问题。

普通模式和 SDD 模式的差别，一句话能说清：前者以聊天上下文为准，后者以规范文档为准。

你可能会问，规范最后不也要加载进上下文吗？对，但它和聊天记录是两回事。

聊天记录像走马灯，内容是流动的、会过期的，跑歪了很难拉回来；规范是人工审查确认后固化下来的结构化文件，就算中途跑歪，你也能拿它当尺子，把 AI 拉回来。

说得再直白点：前者像口头约定，谁记得算谁的；后者像一份写在纸上的制度，随时能翻出来对。约定靠记性，制度靠文件——AI 的记性不可靠，文件可靠。

规范也进上下文，但性质完全不同

换个说法更容易懂：SDD 的本质，是把依赖海量聊天记录的黑盒记忆，换成按需读取、每次只读一小段的白盒档案库。

举两个场景对比。

普通模式下，你得在输入框里反复叮嘱：用 TypeScript 写、错误要用统一的错误类包起来、别用 any。聊上十轮，上下文被冲刷一遍，第十一轮它又开始偷懒写 any。

SDD 模式下，输入框里只聊业务——"新增一个登录接口"。AI 自己会去读项目规范里的代码风格文件，从第一行开始就按既定规则写。

差别不在 AI 聪不聪明，在它有没有一份稳定的东西可以对着看。有团队在落地实践中统计过，把规范前置之后，因为减少了反复返工和对齐成本，整体交付效率能提升三到五成。

AI 做架构设计，落在第二步

那具体怎么用 AI 做设计？SDD 的最简流程是四步，第二步就是落点。

第一步，需求对齐。给 AI 一句话需求，要求它当产品经理反过来问你：指出这段逻辑里所有模糊、有冲突的边界条件。讨论完由它整理成结构化需求文档，人只做审查确认。

第二步，技术方案。把需求文档发给 AI，让它结合项目现有架构，列出影响范围、潜在技术风险，以及一份改动文件清单。这一步生产的其实就是架构设计——谁受影响、风险在哪、动哪些文件。

第三步，精准编码。明确约束：严格按文档执行，只允许改清单里的文件，不许擅自重构没提到的模块。

第四步，对照验收。让它按需求文档和技术文档自检，逐条核对验收项，生成交付报告。

别把把关动作放到最后

这四步里，人类的精力应该放在两头：前两步的文档把关，和最后的验收。中间的编码环节，才是真正可以整段交出去的。

之所以强调"前面"，是因为很多人习惯把检查放到最后——等代码写完再回头审。那时候成本已经付出去了，改一处牵扯三处，你只能在"凑合能用"和"推倒重来"之间选。

把把关提前到文档阶段，有个额外好处：文档是人能看懂的。你不用逐行读代码，只要看它列的影响范围和风险清单对不对，就能拦住大部分方向性错误。

一开始多花的那半小时看文档，通常能省掉后面两三轮返工——这笔账算过几次就很清楚了。

规范分两类，混着放很快就烂

规范听起来简单，但存法有讲究。至少要分两类，它们的保质期完全不同。

一类是"事实来源"，也就是唯一事实：统一的代码风格、数据库表结构、全局路由规则。这类要长期有效，而且必须唯一，不能散落在好几个地方，开发新功能一律以此为准。

另一类是"历史决策"，属于时效文档：某次迭代的需求方案和技术方案。它记录的是当初为什么这么做，功能上线后就可以归档。留着它是为了让以后的 AI 看懂当时的决策意图，避免重复踩坑。

这两类混在一个文件里，很快就会出问题：早就过期的临时决定，会被当成今天的最高原则。

为什么规则不能一次全塞进去？

因为规则给多了，指令遵循度会断崖式下降。

每个会话一次塞太多内容，AI 反而抓不住重点。所以规范体系要靠"渐进式披露"来组织：入口文件当索引，只放路由指引，具体规则按需加载。

比如入口文件里写两条：修改数据库相关代码前，必须先完整读规范目录里的数据库文档；开启新功能开发前，必须先生成本次的需求文档和技术方案。

至于这些指引为什么会被遵守——因为根文件里的规则是在会话创建时就注入到系统提示词里的，属于高优先级触发条件。AI 在生成修改方案之前，会先去读指定文件。既不把几万字的规则一次性塞爆上下文，又能在动关键代码时让规范精准生效。

AI 能做设计的底气，其实在 harness 层

讲到这有个问题绕不开：AI 凭什么能参与架构设计？

拆开主流编程智能体的实现会看到一个反直觉的事实：Agent 的核心循环非常小，二十来行代码——模型评估状态、选一个工具、执行、拿回结果，如此往复。真正的复杂性全在外围，那一层叫 harness。

harness 里管的事，恰好是架构设计需要的：上下文与记忆管理（怎么压缩、怎么把持久记忆注入）、安全执行环境（沙箱隔离、权限门控）、可观测性（结构化日志、实时事件流）。

所以模型能力之外，真正决定"能不能交给它做设计"的，是这些工程化的部分。这也是为什么同样的模型，装在不同工具里表现差一大截。

「不想看」比「看不懂」更危险

最后说个不太好听但很值得听的部分。

一位架构师写过一段自省：他越来越不想看 AI 写的代码了。他说，"不想看"和"看不懂"是两回事——看不懂问题明确，你知道自己欠着这一段；不想看不一定表现为关掉代码，可能只是一个很小的念头，这个地方应该没什么特别的吧。

危险在于，很容易把"我知道它大概在干什么"当成"我理解了这次修改"。这两句话表面很像，只有别人再往下追问才露馅：为什么要新加这一层？已有实现为什么不能继续用？失败之后谁接着处理？

"随时能看"是一句很方便的话。今天能说，明天也能说；只要功能还在往前走，就很难找到一个非看不可的时刻。

文档生成：把过程变成资产

除了设计和审查，AI 在文档这块的用法也变了。

有个例子：一场两小时十九分的直播，把回放文档和音频丢给工具，四十来分钟就输出一份图文并茂的文档，而且截图位置卡得挺准——嘉宾讲某个概念时，它截下了对应的能力构成图。

这类活的价值不在"省一次打字"，而在"过程留痕"。以前要么花几小时重看录像，要么放弃整理；现在变成给它材料、等它交付、你只做校对。

会议记录、评审过程、方案讨论，逻辑是一样的。留下的东西是资产，丢掉的东西下次还得重新讨论一遍。

而且这类文档天然可检索：下次讨论同一个话题，先翻旧文档，比重新问一遍快得多，也不会出现「上次说的和这次说的不一样」。

你的位置变了，还是它的能力变了？

从补全到设计，变的不是 AI 的能力边界，而是你的位置——从"写代码的人"变成"定规范、审方案的人"。

这个位置听起来轻松，其实更考验人。因为规范立得好不好、方案审得准不准，直接决定 AI 是帮你放大判断，还是替你放大模糊。

转变有几个具体参照：以前你的产出是能跑的代码，现在你的产出是能被检查的文档和清单；以前你担心的是写得对不对，现在要担心的是定得准不准；以前你逐行读代码，现在逐条读影响范围。

下次想让它多做一点之前，先问自己一句：我有没有给它一份说得清的规范，和一条看得见的边界。