和强模型协作的正确姿势：模型越强，越要先把「未知」拆清楚，一套可落地的 AI 编程协作方法论

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

这篇文章想说清一件反直觉的事：当你手里的 AI 编程助手足够强，真正卡住你的往往不再是模型，而是你自己没把「要什么」想明白。 核心结论就四句话——第一，你写的提示词、喂的上下文只是「地图」，真正干活的代码库和真实约束才是「领土」，二者之间的裂缝就叫「未知」；第二，未知可以拆成四类，其中「你压根没意识到自己不知道」的那一类最要命；第三，减少未知、为未知留预案，本身就是 AI 编程这门手艺的核心；第四，最好的陪练恰恰是 AI 自己，让它在动手前帮你把盲区一个个挖出来，代价几乎为零。

下面我会把一整套「实施前、实施中、实施后」的闭环流程拆开讲，配上可以直接抄走的提示词模板、一个我自己用代码「剪」视频的完整例子，以及给新手的一份可打印清单。方法本身不挑工具，无论你用的是哪家的编程助手，思路都通用。

想看完整拆解，往下翻。

一、先讲个反直觉的结论：模型越强，卡住你的越可能是你自己

我自己折腾 AI 编程这一年多，被同一个道理反复教育：地图，不是领土。

这句话不是我发明的，它出自普通语义学里一句很老的箴言，原意是说——你脑子里对世界的描述，和世界本身，永远不是一回事。放到 AI 编程这件事上，它突然变得特别贴切。

你写给助手的那份提示词、你精心整理的上下文、你挂上去的各种技能和文档，这些都是「地图」，是你塞给它的一份说明书。而真正要干活的地方——那个盘根错节的代码库、线上跑着的真实环境、绕不开的性能和兼容性约束——才是「领土」。你画的地图再精细，也不可能和领土严丝合缝。

这中间的差距，我习惯叫它「未知」。助手每撞上一处未知，其实都只能猜：按它对「你到底想要什么」的最佳猜测，替你做个决定往下走。任务越长、要动的地方越多，撞上的未知就越多，猜错的机会自然水涨船高。

早些年模型能力还不够，瓶颈明摆着在模型那一头。那会儿你要做的就一件事：拼命把需求写清楚，把边界条件列全，剩下的就看模型能不能扛住。你会经常遇到「它其实懂我意思，但就是写不对」的情况。

可这一两年，情况悄悄反过来了。现在这批新模型是我第一次觉得——产出的质量，居然被「我能不能把未知讲清楚」给卡住了。 换句话说，瓶颈换了位置：从「模型能不能做到」，变成了「你能不能说清楚你到底要什么」。它能力强到什么地步？强到只要你把问题界定明白，它几乎不会在实现层面掉链子；一旦活儿没干好，回头一看，十有八九是我自己在某个岔路口没交代清楚，它替我瞎猜了。

这不是危言耸听。你可以把它想成招了个能力顶尖、执行力爆表、但完全不认识你、也没进过你这家公司的外包工程师。他手速比你快十倍，读文档比你快百倍，可他不知道你们团队那些「不成文的规矩」，不知道这个字段为什么当年要留个坑，也不知道产品经理上周口头改过一版需求。你交代得越含糊，他越会按「行业最佳实践」自作主张，而那套实践未必对你的路子。

我给你举个特别具体的对比，你就懂这个转变有多真切。两年前，我让助手写一段稍微复杂的逻辑，得盯着它、改它、跟它反复拉扯好几轮，因为它总在实现层面出小错——这里少判个空、那里循环边界差一位，我大量精力花在「盯质量」上。而现在，同样的活儿，只要我前期把要什么讲明白，它一遍就能给我干得又快又干净，我几乎不用再逐行挑刺。可代价是，我一旦偷懒没把某个细节想清楚，它会非常「丝滑」地按自己的理解跑完，等我发现不对，往往已经是成品阶段了。你看，我的工作重心是不是明显从「盯它写得对不对」挪到了「我到底有没有说清楚」？这个挪动，就是这篇文章想讲的全部。

莫潇羽@无忆研习社这一年最大的体感就是：模型强到这份上，接下来能不能出活，考验的已经是「人怎么提问」了。

二、"未知"到底是什么：地图与领土之间的那道裂缝

上一节抛了「未知」这个词，这节把它讲透，因为后面所有方法都围着它转。

先给个白话定义：未知，就是「你的地图」和「真实领土」对不上的那些地方。 你以为某个接口返回的是数组，实际它在特定条件下会返回 null，这是未知；你默认这个页面的配色要走冷色调，可你从没跟助手说过，这也是未知；甚至你自己都还没想好登录态要不要支持多端同时在线——连你都没答案的问题，当然更是未知。

这里有个关键点值得停下来说清楚：未知不是「模型的知识盲区」，而是「你和模型之间没有对齐的信息」。很多人一听「未知」就以为是模型不懂某个技术，恰恰相反，大多数纯技术问题模型比你懂得多。真正麻烦的未知，是那些只存在于你脑子里、或者压根还没成形、但会实实在在影响最终产物的判断。

为什么长任务会成为未知的重灾区？因为未知会累积、会连锁。一个短平快的小改动，地图和领土差不多能对上，助手猜错的空间很小。可一旦是那种要动数据结构、跨好几个模块、还牵扯用户可见流程的大活儿，未知就像滚雪球：第一步猜偏一点，第二步在偏的基础上继续往前跑，到第五步可能整个方向都歪了。等你回过神想纠正，代码已经改得七零八落，回滚都费劲。

更扎心的是，未知这东西不会老老实实排队等你处理。我把它们大致分成两种冒头方式：

• 一上来就露面的未知：你动手前稍微想想就能意识到「这里我还没定」。这类相对好办，属于「已经知道自己不知道」，摊开在桌面上挨个解决就行。
• 埋在实施深处的未知：干到一半才突然冒出来。你写着写着发现某个边界情况根本没考虑过；更狠的是，有些未知一露面，你才惊觉整个问题都该换个解法——原来的方案从根上就不成立。

我自己踩过最深的坑，几乎都属于第二种。它的可怕之处在于：等它暴露的时候，你已经沿着错误的路走了很远，沉没成本高得让人不甘心掉头。所以这套方法论真正的价值，不在于「把已知的需求写得多详细」，而在于尽可能地把那些会晚暴露的未知，提前逼到台面上来——趁着改动代价还便宜的时候。

打个不太严谨但好懂的比方：装修房子之前，你会先请人做水电排查、量尺寸、看承重墙在哪。这些动作本身不产出任何「成品」，可一旦跳过，等瓷砖都贴好了才发现墙里有根管子走错了，那才是真正的灾难。AI 编程里的「挖未知」，干的就是水电排查这档子事。

顺带说说一个心理层面的坑，因为它是很多人翻车的根源：人天然会高估自己那张地图的完整度。 心理学里管这叫某种「知识的错觉」——你觉得自己把一件事想明白了，可一旦让你从头到尾讲一遍，或者动手做一遍，漏洞立马就露出来了。你以为需求已经在脑子里成形，实际它可能到处是模糊地带，只是你没意识到而已。

这个坑在 AI 协作里被放大了。以前你自己写代码，走到某个模糊地带会被逼着停下来想清楚，因为不想清楚就写不下去。可现在助手不会停——你没交代的地方，它顺手就替你猜一个填上，流畅地往下跑。于是你那些「其实没想明白」的地方，被它用「看起来很合理」的猜测悄悄糊住了，你甚至察觉不到。等到最后成品和你预期对不上，你才回过味来：哦，原来这里我从来没真正定过。

所以「挖未知」的第一步，其实是先承认「我的地图没我以为的那么全」。这份谦虚不是姿态，是方法——你越是默认自己想得周全，越容易在下面两格（未知未知、未知已知）里栽跟头。我自己现在开工前都会先默念一句：这次我又有哪些自以为懂、其实没定的地方？

三、把"未知"拆成四类，最难缠的是最后一类

光说「未知」还是太笼统，不好下手。这里我借用一个流传很广的老框架——「已知与未知」的四象限。它最早在军事和情报圈里被反复使用，后来在项目管理、风险评估、决策分析里都成了常识工具，本质是一个二乘二的方格：一个维度是「你知不知道这件事的存在」，另一个维度是「你懂不懂它」。交叉一下，就分出四类。

我把它翻译成「人话版」，专门对着 AI 编程的场景讲：

3.1 已知已知：写进提示词里的那部分

已知已知，就是你明确知道自己要什么、也说得出来的东西。 比如「用某某框架、走 RESTful 风格、返回 JSON、字段用小驼峰」。这类信息你能直接敲进提示词，是整份「地图」里最清晰、最靠谱的一块。它是你和助手协作的地基，越扎实，后面越省心。绝大多数人对 AI 编程的理解，也就停在这一格——以为把已知的需求写详细就万事大吉。

3.2 已知未知：你知道自己没想明白

已知未知，是你心里清楚「这块我还没定」的那些点。 比如「用户头像的存储方案我还没选」「并发量大概多少我心里没数」「这个报表要不要支持导出，产品那边还没拍板」。

这一格其实是最好处理的，因为你已经意识到了缺口的存在。军事和情报领域里有个很朴素的判断：知道自己不知道，你就还站在能主动出击的位置上——可以去查、去问、去做小规模试验，把风险控制在可承受范围。放到协作里，最简单的做法就是把这些点明明白白列给助手，让它帮你补，或者干脆让它先给你几个方案对比。

3.3 未知已知：显而易见到你懒得写的东西

未知已知，是那些你根本没意识到需要说、但一看到成品就立刻知道对不对的东西。 审美就是最典型的例子。

你让助手做个落地页，它给你甩了个能跑的版本，你一看：「太丑了。」可如果动手前有人问你「你想要什么风格」，你多半也答不上具体的，只会说「反正不是这个」。这就是未知已知——知识其实藏在你身上（你有明确的好恶），只是它没被显式表达出来，处于「不说出来你自己都没意识到」的状态。这类知识往往是长期经验沉淀下来的直觉、说不清道不明的品味、团队里大家心照不宣却从没写进文档的默契。

3.4 未知未知：你不知道自己不知道

未知未知，是你压根没想过、甚至意识不到自己缺了这块的东西。 这是四类里最坑的一类，没有之一。

坑就坑在：你不知道该问什么问题，不知道什么才叫「做得好」，也不知道这条路上前人踩过哪些坑。你没法主动去查一个自己都不知道存在的问题。军事和风险管理里对这一类的态度很清醒——你无法穷举它，但你可以承认它一定存在，并为「意料之外」预留缓冲和预案。

下面这张表把四类未知和对应的应对姿势拉在一起，方便你随时对照：

再用一张流程图，把「从满脑子未知到可以放心动手」的过程串起来：

flowchart TD
    A[满脑子未知] --> B{这个未知是哪一类}
    B -->|已知已知| C[写进提示词]
    B -->|已知未知| D[列清单, 让助手补齐或给方案]
    B -->|未知已知| E[做可交互原型, 看到实物再拍板]
    B -->|未知未知| F[让助手做盲区扫描, 挖出你没想到的]
    C --> G[未知收敛到可接受范围]
    D --> G
    E --> G
    F --> G
    G --> H[再动手实施]

3.5 一个关键认知：未知是可以「搬家」的

这套四象限最有用的地方，不在于让你把未知分门别类归好档，而在于它揭示了一个动态过程：未知是可以在格子之间搬家的，而你的整个工作，就是推着它们往「已知已知」那一格搬。

顺序大致是这样：先想办法把「未知未知」变成「已知未知」——也就是让你意识到「原来还有这么个问题我没考虑」；再把「已知未知」变成「已知已知」——去查、去问、去做试验，把答案定下来。同理，「未知已知」那些说不清的品味，一旦通过原型被你看见、被你确认，也就升级成了「已知已知」。

我特别喜欢这个「搬家」的视角，因为它把一件很虚的事变具体了。你不再是笼统地「想清楚需求」，而是有个明确的动作：盯着那些还在下面两格（未知未知、未知已知）里的东西，一个个把它们往上搬。 盲区扫描是在搬未知未知，做原型是在搬未知已知，采访和查资料是在搬已知未知。每往上搬一格，助手猜错的空间就小一分，最终产物的确定性就多一分。

反过来也能解释很多人为什么老翻车：他们只在「已知已知」这一格里使劲——把已经知道的需求写得越来越细，却从不去碰下面两格。地图上熟悉的地方越描越清楚，可地图之外的空白，一片都没填。真正的高手，功夫全花在填空白上。

一句话总结这一整节：AI 编程的核心手艺，就是系统性地把未知往「已知已知」这一格搬家。 记住这句话，后面所有招式你都能自己推导出来。

顶尖的 AI 编程高手，未知都很少。你看他们写提示词就知道——要什么门儿清，对代码库和模型的脾气也门儿清。但请注意，「未知少」不等于「不给未知留后路」。恰恰相反，越是老手，越会在动手前给意料之外的情况备好预案。某种意义上，减少未知、为未知做预案，就是 AI 编程这门手艺本身。

好消息是，这不是天赋，是能练的。而且练这门手艺，最好的陪练恰恰是 AI 自己——这一点我们下面细说。

四、给指令本身就是走钢丝：太具体和太模糊都会翻车

在讲「怎么挖未知」之前，得先破一个新手常见的误区：以为「指令写得越详细越好」。

不是这样的。给助手下指令，本质上是在走一根钢丝，左右两边都是坑。

往「太具体」这边偏，你会得到一个死脑筋的执行者。 你把每一步都钉死，它就会一条道走到黑，哪怕跑到半路发现明明该转向、明明有更优的解法，它也会死守你最初的那句话不放。因为你没给它「可以变通」的授权，它只好把你的字面意思当圣旨。结果就是：路明明是通的，它却因为你当初的一句话把自己堵死了。

往「太模糊」这边偏，你会得到一个自作主张的猜谜者。 你只说「做个后台管理页」，剩下的它全按「行业最佳实践」自己脑补。脑补出来的东西未必错，但大概率不对你的胃口——配色不是你要的、交互逻辑不是你想的、字段命名跟你们现有的对不上。你以为省了事，其实是把「猜」的权力全交了出去。

这两头翻车的根源是同一个：你没把未知想在前面。 路上有坑你不知道（未知未知没挖），路明明是通的你也不知道（把本可以灵活的地方钉死了），于是站在原地瞎指挥。

那钢丝到底怎么走？我的经验是分场景拿捏松紧：

• 对「已知已知」，你要具体、再具体。 框架、风格、命名规范、必须遵守的约束，这些是你确定的，说得越死越好，不给它自由发挥的空间。
• 对「未知已知」和「未知未知」，你要故意留白，甚至反过来让它给你选项。 审美这种东西，你与其硬憋一个说不清的形容词，不如让它先做几版让你挑；你没想到的坑，你与其假装考虑周全，不如老实承认「这块我没经验，你帮我想想还缺什么」。

换句话说，具体和模糊不是二选一，而是要用在不同的格子上。你确定的地方给死命令，你不确定的地方给探索空间。很多人协作不顺，不是详细度不够，是把详细度用错了地方——该松的地方钉死，该紧的地方放飞。

我自己有个土办法：动手前先在心里过一遍，这次任务里「我百分百确定」的有哪些，「我其实没底」的有哪些。前者写成硬约束，后者全部交给助手去帮我探。这么一分，钢丝就好走多了。

五、把 AI 当"陪练"：让它帮你把未知一个个挖出来

前面反复说「挖未知」，那到底靠谁挖？答案有点反直觉：最好的陪练，就是助手自己。

道理其实很硬核。想挖出未知，你需要一个「比你懂得多、还比你快」的对手陪你拆问题。而这批新模型恰好满足：它翻你的代码库比你快得多，扫一遍整个互联网上的相关资料更是眨眼的事，大多数话题它懂得比你深，从失败里爬起来重来也比你利索。你熬一晚上查文档才搞明白的坑，它可能几秒钟就替你标出来了。

所以别再把它当成一个「等你把需求想全了再来接活」的工具。正确的姿势是：你先把起点交代清楚，然后让它像个思考伙伴，陪你把未知一个个挖出来。

什么叫「把起点交代清楚」？就三件事：

1. 你现在想到哪一步了。 是刚有个模糊念头，还是已经有了大致方案，只差落地？
2. 你对这个问题有多少经验。 是头一回碰这个领域，还是老手只想找人对齐细节？
3. 你对这套代码库有多熟。 是刚接手两眼一抹黑，还是自己写的闭着眼都门儿清？

这三点交代明白，助手才知道该用什么姿势陪你——是该给你上课扫盲，还是直接跟你抠架构细节。你要是不说，它又得猜，又多一层未知。

这里我想特别强调一个我用得最顺手的招：大多数时候，一个能上手点、能改的 HTML 页面，就是把未知摆上台面的最好方式。 这话听着有点玄，其实很实在——很多未知（尤其是审美这种未知已知）你光靠脑补和文字描述，永远对不齐。可只要让助手先甩给你一个能点、能拖、能改的原型页面，你一看就知道「对」还是「不对」，「未知已知」瞬间就变成了「已知已知」。文字来回描述一小时，不如原型上点两下。

顺便说个我看到很多人卡住的误区：他们把「让 AI 陪练」理解成了「让 AI 替我拿主意」。这是两回事。陪练的意思是，它帮你把问题拆开、把盲区照亮、把选项摆齐，但最终那个「要往哪走」的判断，仍然得你来下。审美好不好、这个取舍值不值、这条路符不符合你们业务的实际——这些恰恰是你身上那些「未知已知」，是你的价值所在，不能全甩给它。

所以正确的分工是：它负责把「你不知道的」变成「你能看见的」，你负责在看见之后做决定。 它挖坑给你看，你决定填不填、怎么填。一旦你把决策权也交出去，它就只能按泛泛的最佳实践替你猜，那又绕回了「太模糊」那头翻车。把这条边界守住，你和它的协作才既高效又不失控。

顺带说一句，用境外的先进模型做这类协作时，别忘了合规这根弦：境外模型的使用需遵守国内网络与内容管理的相关规定，涉及数据出境、内容审核的场景尤其要留意，能用境内合规替代方案的就优先用境内的。这一点后面讲实操案例时还会再提。

好，铺垫到这儿，方法论的「为什么」基本讲透了。接下来进入最干货的部分——一整套「实施前、实施中、实施后」的闭环流程，全是能直接抄走照做的动作。

六、实施前：五个把未知提前摆上台面的动作

实施前这一段最关键，因为此刻改动代价最低。同样一个决定，原型期改，几乎零成本；拖到代码写了一半再改，可能牵一发而动全身。下面五招，我几乎每个稍微复杂点的任务都会走一遍。

6.1 盲区扫描：让它先把你的盲区挖出来

进一个陌生代码库、干一件不熟的活，我第一件事不是让它写代码，而是让它先给我做一次「盲区扫描」。这个叫法是我自己顺口这么叫的，不是什么行业固定术语，你直接理解成「让它帮我查漏补缺、把我没注意到的地方点出来」就行，用中文说、用英文说都不影响它听懂。直接说：

在你动手之前，先帮我做一次盲区扫描（blindspot pass）：
- 找出我这个需求里潜在的「未知未知」，也就是我可能压根没想到的问题；
- 逐条讲给我听，并说明为什么它重要；
- 顺便告诉我，我这段需求哪里写得含糊，怎么改能让你理解得更准。

这一招的妙处在于：它会用它对整个代码库和海量案例的了解，替你标出那些你自己根本意识不到的坑。顺带还能反过来教你「提示词该怎么写」，越用越会写。我头一次在一个陌生老项目里用这招，它直接点出三个我完全没考虑的边界情况，其中一个要是等上线才发现，够我加一晚上班的。

6.2 头脑风暴加原型：看到才知道要什么的东西，先做出来

视觉设计、交互流程这类「看到才知道要什么」的东西，别急着一头扎进后端。正确顺序是：先让它用一个 HTML 页面，甩你四个截然不同的方向，你挑。

先别写后端。针对这个页面，用单个 HTML 文件给我做四个风格/布局截然不同的原型方向，
每个都能直接在浏览器里打开看效果，我挑完再往下做。

前面讲过为什么——「未知已知」在原型期发现，成本几乎为零；拖到实施期才发现，规格上一个小改动，代码可能天翻地覆，回滚都费劲。我把这条奉为铁律：凡是涉及审美和体验的判断，一律先出可交互原型，绝不靠文字硬聊。

6.3 采访：让它一次一个问题地反问你

有时候你自己都说不清要什么，那就把主动权交出去，让它来采访你：

接下来请你像个资深工程师一样采访我，一次只问一个问题，
优先问那些「答案会直接改变架构」的关键问题，
我答一个你再问下一个，直到你觉得信息够动手了为止。

注意那句「一次一个问题」和「优先问会改变架构的」。一股脑抛十个问题，你会答得敷衍；一次一个，你才会真的停下来思考。而「会改变架构」的问题优先，是因为这类问题一旦答错，返工成本最高，必须在动手前就锁死。

6.4 给参考：说不清就别硬说，最好的参考是源代码

描述不清一个效果，是常态。这时候别硬憋形容词，最好的参考是源代码。

你喜欢某个开源库的实现、某个站点上的某个组件，把助手直接指向那个文件夹或那个模块就行——哪怕它是另一种语言写的都没关系。因为它读的是底层代码，不是截图，拿到的细节比你嘴上描述的丰富十倍。你说「我想要那种丝滑的展开动画」，它一脸懵；你把那个动画的源码目录甩给它，它秒懂。

我想要类似这个实现的效果，参考代码在 ./reference/some-lib/src/animation 这个目录，
你读一下它的实现思路，然后用我们项目的技术栈复刻一版，风格保持一致。

一句提醒：引用和参考第三方开源实现时，注意看清楚它的开源许可证，商用场景要确认授权范围，别把不允许商用的代码直接搬进商业项目。这属于工程之外但同样重要的合规意识。

6.5 实施计划：动手前先要一份计划，把最容易变卦的放最前面

万事俱备，最后一步——动手前让它写一份实施计划给你审。而且要明确要求它把最可能变卦的东西放最前面：数据模型、类型和接口定义、用户看得见的流程，这些一旦定错，全盘皆输，必须优先对齐。那些机械性的重构、样板代码的搬运，压到最底下，那部分放心交给它，基本不会出岔子。

动手前先给我一份实施计划，别写代码。要求：
- 按「最可能返工/最影响全局」到「最机械、最放心」的顺序排列；
- 数据模型、类型接口、用户可见流程放最前面，重点标注需要我拍板的地方；
- 纯机械性的重构和样板代码放最后，简单列一下即可。

我审计划的时候，眼睛只盯着最前面那几项。前面对齐了，后面基本就是水到渠成。这一步花五分钟，能省下后面几小时的返工。

6.6 把五招串成一次完整走查（举个通用例子）

单看五招可能还是抽象，我用一个通用化、虚构化的例子把它们串一遍。假设你要给一个已有的内容站加一个「用户收藏夹」功能，你对这套代码半熟不熟。走查大概是这样：

第一步盲区扫描，你先扔一句：「我要加收藏夹功能，帮我做盲区扫描，把我可能没想到的问题讲给我听。」它可能给你标出：收藏的是否要支持分组？未登录用户点收藏怎么处理？收藏数据要不要和现有的点赞表共用一套结构？——这几条里，八成有一两条是你压根没想过的未知未知。

第二步，收藏夹的列表页长啥样你说不清，那就让它出三四版 HTML 原型，你点一点，挑出顺眼的那版，未知已知当场落地。

第三步，它反问你：「收藏上限设不设？」「取消收藏要不要二次确认？」你一个个答，答的过程里你自己也把没想清的地方想清了。

第四步，你说「我想要那种收藏时的心跳动画」，说不清，就把某个开源组件的源码目录甩给它参考。

第五步，让它出实施计划，把「收藏数据表结构」「和现有点赞逻辑的关系」这些最影响全局的排最前面，你重点审这几项；纯前端样式那些放最后。

你看，走完这一圈，一个原本模模糊糊的「加个收藏夹」，已经被拆成一堆确定的决策。这时候再让它动手，几乎不会跑偏。这套流程不挑功能大小，小到一个按钮、大到一个模块，都能照着走，区别只是走的深浅。

把这五招连起来看，其实是一条清晰的收敛路径：盲区扫描挖出你不知道的 → 原型摊开你说不清的 → 采访逼你想清没定的 → 参考帮你精确表达 → 计划把风险按优先级排好。走完这一圈，未知已经被压到很低，这时候再让它放手去实现，出活的质量完全是另一个量级。

七、实施中：只一招，用一份笔记守住计划不跑偏

计划审得再周全，实施过程也一定会出意外。这几乎是铁律——总有你没料到的边界情况，逼得你临时偏离原定方案。这时候只需要一个动作：让助手全程维护一份实施笔记（implementation-notes.md）。

规则很简单：一旦撞上计划外的情况、被迫做了个和原计划不一样的决定，就选相对保守的那个方案，然后在笔记的「偏差记录（Deviations）」小节里记上一笔——为什么偏、怎么偏的、选了哪个替代方案，记完接着干。

这里得把「保守」说死一点，不然容易含糊：它指的是对已有功能影响面最小、回滚成本最低的那个方案，而不是单纯「改动行数最少」。 这两者经常不是一回事——有时候多写几行、做一层隔离，反而比图省事直接改一处旧逻辑更保守。判断的标尺始