为什么你的 AI 编程总在擦屁股，因为你的工具只会写代码不会交付
为什么你的 AI 编程总在擦屁股，因为你的工具只会写代码不会交付
来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 记忆系统, 办公效率, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/5wNJS8bkCR3S_Uh-78m5eg
摘要
关注 「林月半子的AI笔记」，设为「星标」我是林月半子，教你用AI干掉90%的重复劳动！ 前两天刷到谷歌研究员姚顺宇的一个观点：他现在 90% 的代码都是 AI 生成的，剩下 10% 也快了。 我特意去问了一圈以前的老同事，发现还真是——基本人手一个 AI 编程工具，还在坚守"古法手写"的老顽固，要么已经被卷走了，要么正在被卷。 但工具有了不代表体验就好。模型能力是一方面，很多时候体验拉胯不是模型的问题，是工具本身的工程化能力跟不上。代码生成了一堆，来回调试、反复返工，你花在"擦屁股"上的时间比自己写还多。 我一直觉得：AI 编程工具不好用，是在浪费生命。 最...
核心内容
关注 「林月半子的AI笔记」，设为「星标」我是林月半子，教你用AI干掉90%的重复劳动！
前两天刷到谷歌研究员姚顺宇的一个观点：他现在 90% 的代码都是 AI 生成的，剩下 10% 也快了。
我特意去问了一圈以前的老同事，发现还真是——基本人手一个 AI 编程工具，还在坚守"古法手写"的老顽固，要么已经被卷走了，要么正在被卷。
但工具有了不代表体验就好。模型能力是一方面，很多时候体验拉胯不是模型的问题，是工具本身的工程化能力跟不上。代码生成了一堆，来回调试、反复返工，你花在"擦屁股"上的时间比自己写还多。
我一直觉得：AI 编程工具不好用，是在浪费生命。
最近有个变化挺有意思。身边好几个同事悄悄换了个工具叫 Qoder，而且不约而同跟我说了同一句话——"这玩意儿不太一样。"
我一试，确实不太一样。
不太一样在哪？
现在市面上的 AI 编程工具，体验基本都是这样的：你在编辑器里写代码，旁边挂一个 AI 聊天窗，你说一句它干一句，干完你来检查。
这个模式用了半年多，我总结出三个让我越来越烦的问题。
先看个全貌：Quest 视图
打开 Qoder，右上角一键切换，会看到一个全新的界面——Quest。
第一次打开的时候我愣了一下。这不是传统 IDE 里贴一个聊天窗的感觉了，更像是一个项目管理控制台。
三栏布局：
- 左边是任务列表，不同 Workspace 的任务都在这，随时切换
- 中间是对话区，但不是那种无穷无尽的聊天流——它把过程折叠了，只突出结果
- 右边是产物区，代码变更、设计文档、自测报告，全在这
你可以同时开好几个 Quest 任务，每个任务有自己的状态：运行中、等待确认、已完成。就像一个待办看板，扫一眼就知道哪个任务需要你介入，哪个还在自己跑着。
这个体验跟以前完全不一样。以前是"盯着 AI 写代码"，现在更像是"派任务、看结果、做决策"。Qoder 管这个叫"Quest On, Hands off"——放手交付。
光说没用，直接拿自己的项目跑一个给你看。
实战：一句话让 Quest 给我造一个测试框架
我平时做了很多 Skill，全放在一个叫 lin-custom-skills 的仓库里，目前 11 个 skill。这些 skill 基本都是让 AI 生成的，但一直没有自动化测试——每次改完只能手动查 SKILL.md 格式对不对、模板渲染有没有问题、脚本能不能跑通。skill 越来越多，手动测试已经扛不住了。
所以我在 Quest 里丢了一句话：
💬
帮我给这个 skill 项目设计一个自动化测试框架，能批量验证每个 skill 的 SKILL.md 格式是否合规、prompt_template 是否能正常渲染、scripts 是否能跑通。输出一份测试报告
然后 Quest 就开始干活了。
第一步，它先出了一份 Spec。
右边产物区直接生成了一份 skill-test-framework.md，整个测试框架的设计写得很清楚：要验证什么、怎么验证、目录结构怎么组织、输出什么格式的报告。不是上来就写代码，是先把方案理清楚。
第二步，按 Spec 一步步往下走。
右边的进展面板能看到每一步的状态：创建目录结构 ✅、创建验证模块（skill_md、prompt_template、script_check、cross_reference）✅、创建测试用例 ✅、创建报告生成模块 ✅、创建入口脚本 ✅、运行测试验证可用性 ✅——全部绿勾。
第三步，看交付物。
中栏的会话流里能看到最终结果：一个完整的 tests/ 目录结构，4 个验证器模块，配套的测试用例，JSON + HTML 双格式报告生成，一键入口脚本 run_tests.py。底部显示总共变更了 19 个文件，+1381 行代码。
最后，跑一下测试。
python run_tests.py --html，直接出了一份可视化的测试报告：11 个 skill 全部自动发现，199 条测试用例，196 条通过，0 失败，3 条跳过（warning 级别）。
从"帮我做个测试框架"到拿到完整的、能跑的、带可视化报告的东西——全程就一句话。
这就是 Quest 跟传统 AI 编程的区别：不用盯着它一步一步写，描述目标，验收结果。
专家团模式
Quest 视图让我眼前一亮，但真正让我觉得"这玩意儿确实不一样"的，是它的专家团模式。
以前不管哪个 AI 编程工具，本质上都是一个 Agent 在干活。你跟它聊，它写，你看，你改，它再写。任务一复杂，单 Agent 就开始力不从心了。
Qoder 1.0 的做法不一样：不是派一个 Agent 给你，是派一个团队。
💡
一个人从需求分析、写代码、做 Code Review 到跑测试全包，跟一个团队分工来做，效率和质量差得很远。真实的研发团队里，我们不会让一个人干所有事。AI 编程也一样。
Qoder 内置了一套研发专家团，具体怎么运作：
整个过程下来，拿到的不是"AI 说它写好了"，而是一份经过拆分、编码、审查、验证的交付物。
从"它说它做了什么"变成"我可以检查它到底交付了什么"。
实战：用专家团复现一篇火爆论文的 Skill
再来一个真实的例子。
这两天有篇论文在 AI 圈很火——《HeavySkill: Heavy Thinking as the Inner Skill in Agentic Harness》。核心思路很简单：让多个 AI 先并行"独立思考"，各自生成一条完整的推理轨迹，互不干扰；然后再用一轮"主持人审议"把所有思路综合起来，得出最终答案。
论文实测数据很猛：经过这个流程处理后，回答质量甚至超过了理论上的 Pass@K 上限——也就是说，讨论过程中 AI 把不同轨迹里各自正确的片段拼到了一起，推出了任何单条轨迹都没拿到的正确答案。
已经有大佬（向阳乔木）基于这篇论文做了一个 Skill 实现。我就想拿这个需求来试试 Qoder 的专家团——让它帮我在自己的 skill 仓库里，从零开始造一个 HeavySkill。
我在 Quest 里给专家团下了这个任务：
💡
帮我创建一个新的 Skill，叫 heavyskill-reasoning。功能是实现 HeavySkill 论文的两阶段推理框架：
阶段一（并行推理）：对用户的问题同时启动 K 条独立推理轨迹（默认 K=3），每条轨迹在隔离环境中独立思考，互不参照。
阶段二（顺序审议）：将所有轨迹的推理结论和关键步骤汇总，打乱顺序防止位置偏见，交给一个"审议主持人"做综合判断——分类查询类型、逐条评估推理质量、识别逻辑缺陷、跨轨迹综合，输出最终结论。
技术要求：
- 参考我现有 skill 的目录结构（SKILL.md + scripts/ + references/）
- SKILL.md 包含完整的 prompt template，定义并行推理和审议两个阶段的指令
- scripts/ 里写一个入口脚本，接受用户问题，调用 Claude AP
...(内容截断，完整内容请查看原文)
本页由自动化脚本生成，待人工审核补充