【经验总结】最近AiCoding的一些感受

最近AiCoding的一些感受

文章目录

• 最近AiCoding的一些感受
• • 一、突然从prompt转向skill的跨越
  • 二、写好一个skill很重要
  • • [2.1 可以借助 `skill-creator` 来写 Skill](#2.1 可以借助 skill-creator 来写 Skill)
    • [2.2 使用find-skill这个skill帮我查找skill](#2.2 使用find-skill这个skill帮我查找skill)
  • [三、重新认识 Agent：它很强，但很多时候能力上限由使用者决定，"人有多大胆，地有多大产"，充分发挥你的想象力](#三、重新认识 Agent：它很强，但很多时候能力上限由使用者决定，”人有多大胆，地有多大产"，充分发挥你的想象力)
  • • [3.1 很多事情不是大模型"做不到"，而是"你没把它指挥好"](#3.1 很多事情不是大模型“做不到”，而是“你没把它指挥好”)
    • [3.2 Agent 很像"全能但莽撞"的实习生](#3.2 Agent 很像“全能但莽撞”的实习生)
  • 四、不止skill，SDD项目范式横空出世
  • • [4.1 OpenSpec 工作流（概览）](#4.1 OpenSpec 工作流（概览）)
    • [4.2 OpenSpec 工作流（实践建议）](#4.2 OpenSpec 工作流（实践建议）)
  • [五、Agent 与传统 Chat 的最大区别：它可以直接"做事"](#五、Agent 与传统 Chat 的最大区别：它可以直接“做事”)
  • 六、Agent也会偷懒/疲劳：你可以化身"程序员鼓励师"加油打气
  • 七、mcp：用skill写更多很强的mcp服务，无敌组合
  • 八、结语

一、突然从prompt转向skill的跨越

大概去年年底尝试过claude code编写了一些demo程序，发现他用到了skill.md文档，然后agent根据skill文档去编写程序。当时觉得这真的是一个很大的跨越，之前使用prompt的方式编写代码，最大的问题就是需要不断的去对话，对话上下文太多了，ai还会逐渐变的混乱，记不得前面的提示词了。

截图是我用 claude-code 做过一个完整的 Web 版本贪吃蛇游戏，claude-code生成的项目文件夹：

游戏运行起来的截图找不见了！！暂且留白

二、写好一个skill很重要

对比以前"Prompt + Agent 多轮对话"的方式，我更愿意把 Skill 理解为：

把你对任务的理解、工程化约束、验收标准，提前沉淀成可复用的指令模板。

所以，写一个行之有效的 Skill，重要性不亚于编码能力本身。

2.1 可以借助 skill-creator 来写 Skill

如果你不确定 Skill 怎么写，可以直接用官方提供的 skill-creator 来辅助生成和迭代：

• Skill 示例与仓库：
  https://github.com/anthropics/skills/tree/main/skills/skill-creator

2.2 使用find-skill这个skill帮我查找skill

https://skills.sh/

三、重新认识 Agent：它很强，但很多时候能力上限由使用者决定，"人有多大胆，地有多大产"，充分发挥你的想象力

这段时间对 Agent 的认知也发生了变化，主要有几个点。

3.1 很多事情不是大模型"做不到"，而是"你没把它指挥好"

从结果来看，很多任务并非模型能力不够，而是我们的指令缺少：

• 明确的目标与验收标准
• 必要的上下文边界（不能自由发挥到跑题）
• 对输出格式、工程规范、改动范围的约束

把这些补齐后，达成率会显著提升。

3.2 Agent 很像"全能但莽撞"的实习生

和刚工作的新生接触过，我对他们的印象是：让写一个具体的组件、模块代码很快，学习能力也很强（包括我刚毕业工作时也是这这个状态，那会主要还是工作有新鲜感+成就感，现在就一言难尽咯~）。但是经常由于实践缺失，需要进一步完善做出的东西。

所以我更愿意把 Agent 类比成一个能力很强的实习生：

• ①知识面很广、动手很快、实现方案也很发散
• ②有时会莽撞：容易"自作主张"，做出文不对题的事情
• ③遇到复杂上下文时，可能会出现"偷懒/撂挑子"的倾向

因此，和 Agent 协作的关键不是"让它更聪明"，而是：

给它更像真实工程团队一样的规范、边界与流程。

---

四、不止skill，SDD项目范式横空出世

SDD即：Spec-Driven Development规范驱动开发

它的核心思想是：

• 在项目中维护 spec.md、skill.md 等规格文档
• 需求变更先改规格，再让 AI 严格按规格实现

这类流程能有效降低"对话式开发"的随机性，尤其适合多人协作或中大型项目。

如果你对这套方法感兴趣，可以看看 OpenSpec 框架， 如果有使用上的问题，官方文档没说清楚的，让大模型去理解，你直接对大模型提问即可：

• https://github.com/Fission-AI/OpenSpec

下面用「流程图」的方式，把 OpenSpec 的典型使用工作流讲清楚。

你也可以把它理解为：用规范文件把需求到实现的链路串起来

4.1 OpenSpec 工作流（概览）

提出变更 /opsx:propose
生成变更目录 openspec/changes/<变更名>/
proposal.md：为什么做、改什么、影响面
specs/：需求与场景（可验收）
design.md：技术方案与权衡
tasks.md：实现清单（可勾选）
执行实现 /opsx:apply
按 tasks 落地代码与配置
验证：自测/回归/对照 specs 验收
归档沉淀 /opsx:archive
归档到 openspec/changes/archive/<日期-变更名>/

4.2 OpenSpec 工作流（实践建议）

对齐目标与边界
定义可验收场景
任务拆分到可执行粒度
实现后对照 specs
稳定后沉淀
proposal.md
specs/
tasks.md
执行实现 /opsx:apply
验收与修正
归档沉淀 /opsx:archive

五、Agent 与传统 Chat 的最大区别：它可以直接"做事"

传统 Chat 更多是在"给你方法和思路"；而 Agent 则更像一个可以被委派任务的执行者：

• 需要什么上下文，它可以自己去查
• 发现问题，它可以自己改
• 最终目标是交付可用结果，而不是停留在建议层面

---

六、Agent也会偷懒/疲劳：你可以化身"程序员鼓励师"加油打气

当问题变复杂，或者上下文理解成本很高时，模型有时会给出一种"解决不了"的结论，或者在不充分尝试的情况下提前收尾。

我实践下来，一个有效策略是：

• 明确拒绝"解决不了"的结论
• 要求它继续尝试，并提出多种可行方案
• 给出更严格的验收要求、边界条件和失败不可接受的约束

这种"高压推进"的方式确实能显著提升效率。

有个开源项目专门做了类似的 Skill，名字就叫 pua：

• https://openpua.ai/

说实话这听上去有点"邪修"，但我实际试过：一个原本卡了半小时的问题，用上之后几分钟就能定位并解决。

下面是我当时记录的一段 pua Skill 片段（原样保留）：

七、mcp：用skill写更多很强的mcp服务，无敌组合

以前让我自己去实现mcp服务，那是比较费时间的，但是现在完全可以使用创建mcp服务的skill来创建我们所需要的mcp服务。网上有的直接复用，没有的让大模型写一个服务就行了，一般默认使用nodejs、python脚本来实现的。

之前一次ai coding的分享会上，我看到了同事演示他最近半年探索ai，导入+编写了非常多的mcp服务，基本上让ai随时能访问到项目的任何上下文了。

• anthropics公司的mcp-builder skill：https://github.com/anthropics/skills/blob/main/skills/mcp-builder/SKILL.md

• mcp.so: https://mcp.so/

八、结语

回过头看，这一轮体验给我最大的收获是：

• Prompt 是临时口头指挥，Skill 是可复用的"作业指导书"，SDD则是项目级落地方案
• Agent 能力很强，但需要像工程团队一样的边界与流程
• 规范化（SDD/OpenSpec）能显著降低协作不确定性
• 在复杂问题上，"更严格的验收与更明确的约束"往往比"更聪明的模型"更关键
• 想到什么好的idea，不要迟疑，直接上手去验证