iamnotarobot0

我在写方案的时候就会让 ai 把验收标准写好，方案也会走不同的模型 review 。 最后代码写完也走不同的模型来 review ，现在感觉基本 OK ，没有发生过什么大问题。

当然一般都还是会自己看一下的， 不然确实有点不放心。

@ToDayMkCode 搞起来了，在搞一个苹果插件，走走流程。

优秀

1. 我现在直接 mcp 读取需求文档或者 jira 之类的需求工单
2. 走分析需求的 skill ， 给我需要确认的点，我自己确认或者找产品确认，然后使用 A 模型出草稿方案， 使用 B 模型做 review ，方案需要同步 api 协议/写好验收标准，画好架构图/流程图等等
3. 理解技术方案，跟 ai 对话调整方案，然后做技术方案评审
4. AI 本地开发+单测，编译通过通过之后通过 m c p 协议或者 skill 部署
5. 做端到端验证
6. 提测

google chat 也可以做到的。。。

@JinShu app 也不能凭空造， 得收集想法，吐槽，意愿等等。。。

@OumaeKumiko 不能全放 claude.md ，有的可以放 memory ，有的放 skill 。

claude 会给自己存放的边界的。

@OumaeKumiko 我让 ai 根据我的配置产出了一份经验方案，你可以看看

我的体会是，它多数时候不是在编，而是证据不够就把推断当成结论说了。光写一句「请诚实」管不住，我这边比较管用的是这几条：

1. CLAUDE.md 写成可执行的判据，不写态度。 比如「查到 0 条要附同来源的总量，否则只能说没查到，不能说没发生」「结论必须配一条能证伪它的检查」「样本少于 10 条只报现象，不报根因」。每条后面附一句当初踩坑的由来，它在边界情况下自己能判断适不适用。
2. 已经拍板的事单独列一张「禁提清单」，写明口径和日期。旧事实不删，标「已作废」并写原因，免得它从旧文档里把错的捡回来。
3. 数字不让模型自己算，一律由脚本或查询产出，它只负责解读。我周报里手写的查询翻过两次车，共 8 个数字。
4. 证伪交给独立的 subagent：只读权限，默认立场就是证伪，拿不准判「证据不足」。重要结论先过它一遍。自己审自己，总会偏向刚写的东西。
5. 每个 skill 都来自一次具体的翻车，第一步永远是「先证实现象是真的」。每被纠正一次，就按「下次谁会犯错」沉淀到 CLAUDE.md 、memory 、skill 或脚本里。

它还是会犯错，只是同样的错很难再犯第二次。

@leang521 我 9 月份注册了个账号， 网页版可以聊天，我还特意聊了几天， 才去打开的 app ，结果还是要手机号验证