Rust 并发、异步编程实践经验实用指南
2026-10-14 3467862
2026-10-14 0
AI 编程助手处理单点修改时通常表现顺畅，但任务一旦跨越多个模块、经历多轮决策，冗余上下文、错误假设和缺失的验收标准就会不断放大偏差。要让复杂开发过程保持稳定，需要把模型置于一套可检查、可回退、可复用的工程流程中，并逐步管好上下文、需求、验证与经验沉淀。
复杂任务能否稳定产出,取决于四层工程机制是否同时到位——上下文管理、需求对齐、结果验收、流程固化;而不取决于换用更强的模型。
这四层构成一个自上而下的闭环:
上下文管理(让 AI 始终在能力最强的区间执行) → 需求对齐(先确认做的是对的事) → 结果验收(用客观方法证明做对了) → 流程固化(让这次的成功可以被复用)
验收不通过就回退到开发重来,通过则提交代码并沉淀经验。跑得越多,流程越顺,输出也越稳。以下按这四层展开,每层先给结论,再给支撑该结论的做法,操作示例以 Claude Code 为主。
先回答一个前置问题。小任务之所以输出稳定,是因为整个任务能装进模型"注意力最集中、判断力最强"的那个区间(以下称"聪明区")——目标清楚、上下文干净、一步就能验证对错。复杂任务不稳定,本质上不是模型能力不够,而是这四件事至少有一件失守了:
下面四层,分别针对这四个失守点给出解法。
结论:上下文不是越长越好,管理的目标是在有限注意力下持续提供最关键的信息。做到这一点靠四件事——控制有效占用、实时监控占用、分层组织规则、阶段清零。
1. 控制有效占用 个人经验是把占用控制在 40% 以内作为警戒线,但这只是经验参考,并非有公开数据支撑的行业标准,不同模型和任务下实际边界会有差异。比数字更可靠的判断信号是:任务目标、已定决策、验收标准这些关键信息,是不是一眼还能看到——需要翻回很远才能找回来,说明该处理了。
2. 实时监控,及时压缩或重置
/context 随时查看占用构成——大头往往是读过的文件和命令输出,而非对话本身;/statusline 把占比常驻状态栏;/compact,并附保留指令,例如:"保留接口约定、验收标准和未完成任务,丢掉调试过程";/rewind),不要在错误状态上追加纠正——追加会把错误一起留在上下文里。同一问题连续纠正两次仍未解决,就不要试第三次,直接 /clear 重写提示词;CLAUDE.md 里写好压缩保留指令,因为自动压缩触发时,往往正是上下文最满、判断力最弱的时候。3. 分层组织规则,按需加载
CLAUDE.md 主文件只保留项目概览、规则索引、每条规则的触发条件;细节拆到独立文件,索引写成"什么场景读哪个文件"(如:改数据库 → 读 docs/db-rules.md)。必须每次都发生的硬约束(提交前跑测试、危险命令拦截)不要只写文档——写进 hooks 才是确定性,写文档只是建议。
4. 阶段清零,靠文档续接
复杂任务分阶段执行时,当前阶段完成后主动清零上下文,靠引用独立文档继续下一阶段。清零前先"存档"——进度写进 docs、代码提交到 git,这是清零的安全绳。之后新开会话,一句话续接:"读 docs/<需求名>-对齐文档.md,从任务 3 继续"。这份续接文档从哪来,是下一层"需求对齐"要解决的问题。
结论:需求对齐是为了避免 AI 在没搞清真实意图前就开发。做法是把规则固化进系统提示词——每次收到任务,先结合现有代码分析合理性、找冲突,有歧义就用 3–5 个问题确认,最后整理成文档。
1. 对齐什么 收到任务先做一轮代码调研,产出两张清单:冲突点(需求与现状矛盾的地方)、待确认项(不确认就会选错方向的隐含假设)。有冲突先确认,不带错误假设往下做。
2. 怎么对齐 存在歧义时一次性提 3–5 个关键问题,而不是边做边猜。格式上做到"有选项、有推荐":
【问题 2/4】新老用户表怎么切换?
A. 保持双写,新表先只读(推荐:回滚成本最低)
B. 直接切到新表并删除旧表(最快,但出错没有退路)
C. 双写 + 灰度开关(最稳,实现成本最高)
能从代码里查到答案的不要问用户;只问会改变实现方向的分叉。用户答不上来或答案矛盾的问题,不要替用户拍板——转为"待验证假设"写进文档、标注风险点,在最小可验证环节优先验证掉。
3. 对齐产物
整理成一份独立文档放进 docs:
docs/<需求名>-对齐文档.md
## 目标:一句话说清要什么
## 现状与冲突:任务与现有代码结合分析的结论
## 关键决策:3–5 个问题的确认结果(含未采纳方案及原因,含待验证假设)
## 任务拆解与依赖顺序:按最小可验证粒度逐条列
## 验收标准:每条任务的客观验证方式(命令 / 数据对照)
这份文档正是支撑上一层"阶段清零"的续接入口。
结论:必须给 AI 一个可以客观验证是否通过的方法,且验证者要独立于开发者本人。做法是纵向拆最小可验证单元、多方法交叉验证、独立 Agent 审查、修复从复现开始。
1. 纵向拆解,而非按层分批 不要先把所有 UI 做完、再统一做接口、最后接数据库——这样每层做完都验证不了实际效果。应该把需求拆成最小可验证粒度,每个任务从入口打通到落库,一条做完测试通过再做下一条。判断标准:说不清"怎么看到它成了",粒度就不对。
2. 多方法交叉验证
数据对不对必须用多种方法验证。例如采集内存使用数据,开发完成后要再用 adb dump memory 拿一份数据做对比,两者一致才能确定可用。如果结果对不上,不要默认以某一方为准去"消除分歧",而要当成新疑点:先确认两种方法测的是不是同一口径(采样时间点、单位、统计范围),排除口径问题后仍有差异,再引入第三种独立方法或人工核实。开工前先回答:"这个功能'对'的证据是什么?"——优先选能拿到客观数据的验证方式,而非"看起来能跑"。
3. 独立 Agent 审查 让 Agent 审查自己开发的功能,答案往往是满意的,所以要新开一个干净上下文的子代理,喂给它任务目标与验收标准、本次 diff、相关文档:
你是独立审查者,不要复述代码。输入:任务目标、验收标准、本次 diff。
逐条核对验收标准是否真的满足,每项给出证据;
找出:漏改的调用方、未覆盖的边界、以及"不可能失败"的测试。
输出:不通过项清单(每项附证据与复现方式);通过项只列一行。
另一个廉价有效的抽查:故意把实现改坏一处,看测试会不会变红——不会红的测试等于没有测试。审查 Agent 自己也可能判断错误,所以它给出的"通过"结论最好也用抽查再验证一次,而非当作绝对可靠的终点。
4. 红绿开发,修复从复现开始 采用红绿开发(TDD):先写失败测试(红),再写实现让它通过(绿),之后重构。红的阶段要确认失败信息符合预期,而非随便红了就算。出现 bug 时,"可复现"是修改的准入门槛:先构造最小复现(能稳定触发,只凭阅读代码"看出原因"不算数)→ 两向验证根因(消除它问题消失、恢复它问题再现,两个方向都成立才算真实根因)→ 复现用例留下来做回归,由红转绿才算修完。复现不了的 bug 先别动手,改完也无法证明改对了。
结论:把上述流程固化成可复用机制——验证通过就提交、出错就沉淀、用 workflow 编排全流程,复杂任务的稳定输出才能一次次复现。
1. git 管理:验证通过必须提交 按最小任务提交,一个最小可验证任务验收通过就提交一次,回退点越密出错代价越小;提交信息写清"做了什么 + 怎么验证的";每次清零或阶段收尾前先提交——它是清零的安全绳,也是出错时唯一可靠的回退路径。出错时就近回退到最近一次"绿灯"提交重来,不要在错误上打补丁。
2. 错误经验沉淀 AI 出问题时,需要人或 Agent 主动总结记录,用于后续避免类似问题——这一步目前更多依赖主动引导,而非系统自动完成。两个触发点:同一坑连续第二次出现、每次 bug 修完(尤其根因不显然时)。用四要素记法:触发条件、错误做法、正确做法、怎么检测——缺了"怎么检测",下次照样发现不了。记进 Claude Code 记忆或项目规则文件,新任务开工前让 agent 先查一遍。
3. workflow 编排 整条链路:
对齐 → 拆解 → 开发 → 验证 → 提交 → 沉淀
↑ │
└─ 不通过 ┘(回退重开发,直到通过)
落地步骤:先把流程文档化,每一步产物明确(对齐产出文档、开发产出通过测试的代码、验证产出证据、提交产出回退点);再把步骤交给 workflow,每个阶段对应一个 agent 职责,"验证不通过 → 回退开发"写成显式分支;不必一次到位,先固化最痛的一段(通常是"验证 → 提交"),跑顺了再串下一段,每跑一轮把新踩的失败模式回填进记忆和流程。
上下文管理
/context 看占比;信息开始翻找困难就在最近断点处理(40% 仅作参考)/statusline 常驻占比/compact,附保留指令/clear 重写CLAUDE.md 只放概览+索引+触发条件,细节按需加载需求对齐
结果验收
流程固化
小任务靠模型能力就能完成,复杂任务的稳定性则要靠工程化流程。上下文管理让 AI 在聪明区执行,需求对齐保证做对的事,结果验收用客观方法证明做对了,流程固化让一次成功变成每次可复用。四层构成闭环:验收不通过就回退到开发,通过则提交并沉淀经验;流程越用越顺,输出也越来越稳。