这次表面上只是把新版引导页接进原有启动分流，真正难的却不是接页面本身，而是别把原来的启动判断顺手改掉。它最后能稳住，靠的也不是一句任务描述，而是开工前先把不改范围、关键回归和交接方式都写清楚了。也是到这周我才反应过来，自己前面这些零散做法连起来，已经很接近一套轻量的 Harness Engineering。
开头
这周有个任务，表面上看并不大：
把新版引导页接进原有启动分流。
如果只看结果，它很像一次普通的页面替换。
用户启动 App，原来会进旧 Welcome 的地方，现在希望接成新版引导页。
乍一看，好像就是：
- 找到启动入口
- 把旧页面替掉
- 跑一遍流程
这种任务如果只丢一句话进聊天框里，也不是不能做。
一句 把新版引导页接入旧启动流程，听起来已经够像一个明确需求了。
但真正回到项目现场以后，我最先紧张的，不是代码能不能改出来，而是另一件事：
这条线太容易被误做成“顺手重写首进流程”。
因为它后面连着很多原来的启动规则：
agreeourprivacy还在控制首进分流- 远端
A/B还在决定是不是走new - 原来的隐私页和订阅页承接顺序不能乱
- 这一轮只能替换旧 Welcome 的承接位
- 不能顺手把新版引导页完成态抬成新的启动主判断
也就是说，这次任务真正怕的不是写错一行代码，而是：
把“替换页面承接位”误做成“重写启动逻辑”。
如果这时候只让 AI 按一句模糊描述开工，它很可能会做出一件“代码上也能跑”的事：
- 重写首进判断
- 绕开旧的远端分流
- 或者干脆把新版引导页完成态接成新的总开关
这不是模型笨。
这恰恰说明了一件事：
高风险任务里，AI 最容易误改的，往往不是某行代码，而是原来的判断和走法。
1. 这次任务真正难的，不是接一个新页面，而是别把原来的启动判断改掉
我后来回头看这轮材料，最值钱的地方其实特别具体。
真正让这次接入没有滑向“大改启动逻辑”的，不是聊天框里某一句话，而是开工前已经先把边界钉死了。
这次最重要的第一份材料，是 preflight。
里面先把几件最危险的事说死：
- 这轮只替换页面承接位
- 不改
agreeourprivacy原来的判断方式 - 不改远端
A/B的控制方式 - 不引入新版引导页完成态作为新的启动主判断
- 改之前必须先核对
main和必要历史提交
而对应的 current-task 又继续把目标压得更窄：
- 在不改变原有启动分流规则的前提下接入新版引导页
- 只替换旧 Welcome 的承接位
- 其他启动链路一律不扩改
后面还有一份 关键路径回归，专门把提交前必须看的几条路径列出来：
agreeourprivacy == false且 A/B =newagreeourprivacy == false且 A/B !=newagreeourprivacy == true且已是 VIPagreeourprivacy == true且非 VIP
这三份东西连起来看，真正值钱的不是格式，而是它们把最容易靠临场理解出错的几件事提前做掉了：
- 这轮到底改什么
- 这轮明确不改什么
- 哪些原来的判断和走法最容易被顺手重写
- 改完以后该按哪些路径回归
一旦这层先有了，AI 后面做的才更像“在边界里实现”，而不是“边写边猜需求”。
所以我现在越来越觉得，高风险任务里，开工前真正该先写清楚的，不是“准备怎么改”，而是：
哪些东西绝对不能被顺手改掉。
2. 这三周真正慢慢长出来的，不只是一套开工顺序
如果只看单轮对话，很容易以为最近最大的变化只是：
- 任务描述写得更顺了
- 需求拆得更细了
- 对模型的要求更清楚了
这些当然都是真的。
但我把 week1 ~ week3 沉淀下来的工作文档和工作总结重新对着看，反而更确定，真正慢慢长出来的不是这些表层动作，而是一套更稳定的开工顺序。
说实话，在这周四之前，我并没有想过自己是在做什么 engineering。
前面这些动作一开始都很碎，也都很具体：
- 这里怕 AI 顺手把旧判断改掉，就先补一份
preflight - 那里怕下一轮接不上，就再留一份
handoff - 某条链路每次都容易回归漏掉，就单独写一份关键路径清单
- 真机问题反复讲不清，就把回图和红框标注也固定下来
当时我脑子里想的，其实都不是“我要搭一套什么环境”。
我只是不断在补那些最烦、最容易返工、最容易靠记性出错的地方。
直到这周读到一些公开资料和自媒体内容，我才发现：
原来我这三周不是在零散补文档，而是在一点点给 AI 搭一套更稳定的开工环境。
现在一轮任务下来，仓库里已经不会只剩聊天记录了。
开工前，常见的是：
- 长期记忆文档
- 当周工作集
- 当前任务文件
- 高风险任务的
preflight（开工前核对）
改动过程中，会继续补：
- 关键路径回归
- 真机回归记录
改完以后，还会留下：
handoff（交接记录）retrospective（复盘记录）
这些东西单独拿出来都不神奇。
可一旦它们开始按顺序一起工作，性质就变了。
因为 AI 不再是被临时叫来写一段代码。
它每次开工前，已经默认先知道：
- 应该先读哪些材料
- 哪些区域不能顺手扩改
- 改完以后拿什么来验
- 这一轮结束后，怎么把状态交给下一轮
也就是说，真正稳定下来的，不是“这一轮怎么说”，而是：
下一轮到底从哪里开始。
这也是为什么我现在会觉得，项目里真正拉开差距的，往往已经不是某次回答写得多漂亮，而是你有没有先把这套开工顺序先搭起来。
3. 这套顺序真正压掉的，不是代码量，而是最烦的几种返工
如果只看“AI 写代码”，最容易被看见的当然是速度。
但真实项目里，最拖人的成本往往不长在“写出来”这一步。
这三周里反复出现、后来才慢慢压下去的，主要是下面几种损耗。
1. 每一轮都得重新解释背景
没有记忆文档、没有当前任务文件的时候，很多关键信息都散在聊天里。
下一轮一开工，经常先花掉一大段时间，把背景再说一遍。
只要这些事实开始进仓库，这个损耗就会立刻下降。
2. 表面改的是页面，实际误伤的是原来的判断和顺序
这次新版引导页接启动分流就是最典型的例子。
你明明只想替换页面承接位，最后最容易出事的，却是原来的判断方式和后续承接顺序。
没有 preflight 这一层，AI 很容易把“替换页面”做成“重写流程”。
3. 这一轮看起来做完了，下一轮却接不上
handoff 和 retrospective 的价值，不在于流程感，而在于它们让下一轮不用再靠翻聊天记录，去猜前一轮到底做到哪了、哪些已经确认过、哪些区域不能再动。
4. 听起来像对了，结果却并不稳
真机回图、红框标注、单轮单焦点、回到已认可版本继续收口，这些动作看起来都很小，但它们其实一直在做同一件事：
把“看起来能跑”和“真的改对”分开。
像订阅页视频“看起来被放大播放”这种问题，如果没有单独的真机回归记录，下一轮就很容易把：
- 已经确认过的顶部对齐
- 已经确认过的不改范围
- 下一轮唯一聚焦点
又重新打散回聊天里。
所以我现在再看这套协作，觉得它最值钱的地方已经不是“模型偶尔能写出多漂亮的代码”，而是：
它在把最容易反复出错的那几处，慢慢从靠记性提醒，变成默认先有约束。
4. 也是到这周我才知道，这套东西原来已经很接近 Harness Engineering 了
我这周读公开资料和自媒体一些内容时，一个很清楚的感受是：
大家现在说的 harness engineering，重点根本不在某个工具名上。
它更像是在问：
你有没有给 AI 搭一套可读、可控、可验证、可复用的工作环境。
我看到这里，才第一次真正反应过来：
前面这些看起来很碎的东西，原来并不是“我最近多写了几份文档”这么简单。
它们连起来以后，已经在承担一套更完整的作用：
- 让 AI 开工前先知道该读什么
- 让高风险任务先把边界钉死
- 让提交后的验证有固定抓手
- 让下一轮不用再靠翻聊天记录重新接线
拿这个标准回头看，这三周里已经能看到几个很明确的信号：
- 关键知识开始留在仓库里，而不是只留在聊天记录里
- AI 的开工顺序是被设计过的，不是随手开始
- 高风险任务会先做
preflight - 改完以后有 handoff 和 retrospective
- 真机回图和红框标注开始承担稳定验收角色
换句话说，你现在已经不只是“会临时给 AI 描述一个任务”。
你其实是在给 AI 搭一个：
- 不容易偏航
- 不容易返工
- 可以交接
- 能连续推进
的协作环境。
如果一定要给它一个更接近公开讨论的名字，那我也是到这周才意识到，它其实已经很接近 Harness Engineering 了。
5. 但它现在还不是满配，更像一套人工主导的轻量版本
这点也要说清楚。
我不觉得现在这套东西已经完全成熟。
它离更完整的状态，明显还有差距。
比如：
- 很多规则还需要你本人提醒
- 很多验证还强依赖你自己真机回图
- 统一的机器可读状态入口还不够强
- 一些自动化约束还没有真正接起来
所以更准确的说法不是“已经有一套完整系统了”，而是：
已经有了一套高质量、强约束、文档驱动、人工主导的轻量版本。
它还不满配，但已经和“临时找 AI 帮忙写代码”不是一回事了。
最后
这次新版引导页接入任务，对我最大的提醒不是“高风险任务要更小心”这么简单。
它真正让我看清的是：
高风险任务里，最先该被写清楚的，往往不是准备怎么改，而是哪些原来的判断和走法绝对不能被顺手重写。
一旦这一层开始先被写进 preflight、current-task、回归清单和交接记录里，很多人嘴里说的“AI 协作”，其实就已经不是临时聊天了，它已经开始变成一套能长期工作的项目协作环境，而我也是到这周才第一次反应过来，原来自己前面不是在零散地补几份文档，而是在项目里一步步走向 Harness Engineering。
