痛点：
-
ai coding 的产能相当强大，在复杂功能开发过程中， 如果前期方向错了，代码错误堆积会超出个人可掌控范围，难以 review
-
在 ai coding 的流程中需要人肉收集 context（之前的日志报错、方案前后改动原因），并同步更新给 AI，如果发现 bug/设计上的问题，需同步修改 a. 设计/规划文档 b. 测试脚本 c. 前后链路，
-
不知道 ai 写的代码什么时候是对的，什么时候会出错，需人工对齐迭代 bug/漏洞/遗漏点/关键设计，如果人工 review，那反而更累了 (openclaw 作者一天 100 多个 commit，都不自己 review，只验证是否达成了目标)
流程：
-
先自己学习理解相关功能，不要把自己的思考也外包给 AI，否则会屁股指挥脑袋
-
头脑风暴，收集整理相关材料证据到 features/references 目录，补充 AI 实现过程中可能需要参考的细节证据（如参考 opencode 对于提示词的组织方式，各个段落详细的提示词材料）
-
proposal 驱动模式，确保 proposal 规划在掌控之内，个人可 review，不做详细 plan：
a. 代码修改的 diff 已经最精炼的说明
b. 只记录实现过程中最关键的决策/约束，并对齐对业务的关键约束/理解
c. 让 AI 画好时序图、流程图 （mermaid flowchart/sequenceDiagra
-
已知:当前现状是什么，想要达成的目标又是什么，关键构架设计(流程图，时序图)，关键约束/决策是什么 问:为了验证这个 proposal 的意义 问:为了达成我们的目标 (objective)，该怎么通过关键结果验证 (key result)
-
根据已有 proposal 做 writing plans，每个 plan 拆解成若干小目标，然后去进行执行
技巧:
-
review 钩子，通过 skill 自动调用 claude code 产生 review handoff 的 prompt，由 codex 接收 prompt 并进行 review，同时自动返回结果
-
claude handoff 插件，在聊天过程中，100 多 k 上下文或者想要起一个新对话的时候，就调用插件生成交接文档，让下一个 llm 能接力工作
-
ralph-loop，对于写好的代码，可以设置明确验证目标，来自动跑实验验证，汇总相应指标给出结果
