别怪 AI,错的是你以为放了 AGENTS.md 就能一劳永逸了
我们每天都在大量使用 Cursor、Claude Code、Trae 这些 AI 编码工具。
但你有没有停下来想过一个问题:
你和 AI 的协作效率,到底处于什么水平?
是好,是坏?
以前我完全没有标准,只能凭感觉。今天写代码很顺,就觉得 AI 极其牛逼;明天 AI 陷入死循环,就骂它是个人工智障。
这种“凭感觉”的时代,差不多该结束了。
这就是我为什么想做 AI Growth Mirror(AI 协作成长镜)。
我想做一面镜子,帮开发者照出自己和 AI 协作里的真实行为:什么时候框定清楚了,什么时候只是把 AI 推着跑,什么时候看起来很忙,其实没有收口。

但这个工具做着做着,我自己也被它反过来教育了一次。
不止一次。
一、我一开始也被 Prompt 分数打脸过
老实说,我一直没有那种“天天背爆款 Prompt 模板,生怕少写一个词大模型就不干活”的 Prompt 焦虑症。
从开始深度用 AI 编码那天起,我就更像一个协作框定者。
我在乎的是:这次任务要干什么,哪些东西不能碰,最后怎么判断它做完了。至于第一句 Prompt 是 30 个字还是 300 个字,我没那么执着。
结果很讽刺。
AI Growth Mirror 早期版本里,评估算法还没完全摆脱“Prompt 完备性打分”的惯性。于是我自己跑出来的 Prompt 分数,低得可怜。
这就很尴尬。
我明明每天都在高强度用 AI 做复杂研发,但工具告诉我:你 Prompt 写得不够完整。
后来我意识到,问题不在我是不是写了“完美 Prompt”。问题在评估标准本身还停留在 Prompt 时代。
所以我后来把产品重心往后挪了一大步:从“你第一句话写得好不好”,挪到“整个协作过程有没有形成任务契约、有没有推动执行、有没有验证收口”。
Prompt 评估没有消失。
它只是从“主裁判”,降级成了证据之一。
真正决定成熟度的,不再是你首轮堆了多少背景,而是你有没有把 AI 放进一个可控的工作现场里。

这面镜子让我发现,大模型编码工具的提效,根本不是去堆砌无聊的 Prompt 咒语。
它更像一场工程管理。
你要管目标,管边界,管执行,管偏航,还要管最后有没有证据证明它真的做完了。
二、AGENTS.md 是法典,但它不是本次任务的合同
在 v1.0.0 开发时,我的验收标准的分很低,有个问题把我卡住了很久。
“既然我已经有了全局 Rule,比如 AGENTS.md,也有 Skill 约束 AI 怎么读写、怎么验证。为什么 AI Growth Mirror 还会因为我首轮没有手写验收标准,就扣我的协作框定分?”
因为如果一个人已经把规则、Skill、工作流都沉淀好了,你还逼他每次都在第一句话里手写一大段“目标、范围、验收标准”,这不叫成熟。
这叫折磨人。
后来我把这个问题拆成了两个东西:
Rule / Skill 是法典。
它规定的是 AI 平时应该怎么做事。
比如:
-
• Windows 下跑命令用
pwsh -
• 改文档前先备份
-
• 报告模板改动不能只跑单测
-
• 不要在 CLI 里写第二套 generate 流水线
这些都很重要。
但它们回答的是 How。
本次任务的动态合同,回答的是 What 和 Done-state。
这一次到底要修哪个问题?
只允许改哪些文件?
跑哪条命令才算过?
如果生成的是报告,验收到底是 pytest 绿,还是 HTML 真能打开,还是 summary 里字段也要对?
这部分,AGENTS.md 没法提前替你猜。
所以我后来改掉了一个过于粗暴的判断:不是“用户首轮没写验收 = 协作框定差”,而是要看在 AI 真正动手前,现场有没有形成一个有效任务契约。
这个契约可以来自用户首轮。
也可以来自 Skill / Rule。
也可以来自 Agent 自己复述出来的实现计划。
但总得有人把它说清楚。
没有合同,法典再厚,AI 也可能很守规矩地把事情做偏。
三、我最近就被这个坑打过脸
说一个很小的 bug。
但我印象很深。
AI Growth Mirror 里有个区块叫 work_focus,用来告诉你最近到底在用 AI 做什么。
有一次我们发现,在证据不足的时候,它居然还能显示出类似“推进当前交付任务”这种话。
听起来没毛病。
但问题是:没证据。
这种话最危险。它不像报错那样刺眼,甚至看起来还挺合理。可它本质上是在用一个通用结论假装理解了用户。
我第一反应是修展示层。
把默认文案删掉,加一个“没有足够稳定的会话语义”。
看起来闭环了。
结果用户追了一句:
LLM 提示词不也得改吗?
对。
真正的问题不在前端,而在上游的证据合同没有压住。
你不能只告诉页面“别乱说”。你还得告诉 LLM:没有证据就闭嘴。
后来我补了 session_read 的 Evidence contract:
-
•
work_summary必须来自真实 evidence packet -
• 没证据就保持空
-
•
work_intent_mix不能因为看到工具调用,就硬猜一个默认主意图
然后再加测试锁住它。
这个小 bug 反而让我更确信一件事:
Rule 是长期纪律,Contract 是本次任务的刹车线。
长期纪律告诉 AI 平时别乱来。
本次合同告诉 AI:这次到底什么能说,什么不能说;什么算完成,什么只是看起来像完成。
四、还有一个误判:讨论方案,不等于目标锁定慢
v1.0.0 里我还修了另一个老问题。
以前的算法只要看到用户“在 AI 写入第一个文件前对话了很多轮”,就会扣掉“目标锁定速度”。
这听上去合理。
但实际不一定。
很多高质量协作,一开始就是不该写文件的。
比如你让 AI 先读架构原则,先走 Skill,先讨论方案,先看历史问题。这个阶段如果 AI 一上来就改文件,反而是坏事。
我自己在这个项目里就经常这样干:先读设计文档,先看规则,先核对 git diff,确认边界,再动手。
这不是拖延。
这是侦察。
所以 v1.0.0 里我补了几类信号:
-
• 写入前如果全是只读侦察,不再普通扣目标锁定速度
-
• Skill / Rule / Workflow 形成的任务契约,也计入有效契约
-
• 构建、编译、
.ps1、.bat这类工程验证,不再被当成“没有测试” -
• 报告里新增任务契约来源和履约率,看的是“有没有合同”以及“最后有没有按合同收口”
这一步很关键。
因为它让 AI Growth Mirror 不再粗暴地奖励“越快改文件越好”。
真正成熟的 AI 协作,不是快。
是该快的时候快,该停下来对齐的时候停下来。

五、我现在对 AI 资产化的理解
做完这个工具,我对“AI 资产化”的理解变了。
以前我会觉得,资产化就是写 Rules,写 Skills,写一堆可以复用的 Prompt。
现在我觉得还不够。
这些东西当然重要。它们是武器库,是战术册,是长期纪律。
但如果没有一面镜子,你其实不知道它们有没有真的生效。
你写了 AGENTS.md,AI 真的读了吗?
你沉淀了 Skill,它真的被唤醒了吗?
你要求每次验证,最后是真的跑了报告,还是只跑了 lint 就收工?
你以为自己在做复杂研发,结果会不会只是修改很多文件,却没有收口证据?
这就是 ai-growth-mirror[1] 在我的体系里想补上的那块拼图。
它不只是看你用了多少 AI。
它看的是:你的 AI 协作系统,到底有没有稳定地产生结果。

如果你也每天在大量使用 AI 编码工具,你可以试一下:
# 1. 下载 并进入目录
git clone https://github.com/yxkong/ai-growth-mirror.git
# 2,初始化
uv sync
# 3,初始化配置,deepseek-v3就可以
cp config.example.yaml config.yaml
# 4. 一键生成本地评估 HTML 报告
python -m ai_growth_mirror.cli generate
打开 ai-growth-mirror.html 后,不要先盯着总分看。
先看三件事:
-
• 你是不是经常没有任务契约就开工?
-
• 你的验证是不是只停在 lint / compile?
-
• 你的 Rule 和 Skill 有没有真的被触发、被执行、被收口?
这三个问题,比“我用了多少 AI”重要得多。
看清自己,才能驯服 AI。
如果你觉的好用就star一下吧,感谢。另外分享下自己的研发技能,已经成体系了。后续会写文章介绍下。
https://github.com/yxkong/agent-hub-share
引用链接
[1] ai-growth-mirror: https://github.com/yxkong/ai-growth-mirror
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐



所有评论(0)