AI 辅助开发实践分享

本文分享我摸索出的 AI 辅助开发方法,基本是对前两篇文档的总结,前两篇文档讲的是思路,这次通过skill固化成了开发流程. 我日常使用的开发工具是opencode，日常使用的模型为 GPT5.4、Kimi2.6、GLM5.1。

AI 开发的特点

AI 的局限性

• • 没有持久记忆：每次新对话都是一张白纸，上一次会话中搞清楚的业务逻辑、架构决策、踩过的坑全部丢失
• • AI幻觉： AI输出的不一定是对的，对不对需要验证
• • 代码只能告诉 AI "what"，不能告诉 "why" 和 "why not"：AI 看到一段代码，不知道为什么这样写、曾经踩过什么坑、哪些看起来可以改但实际不能动
• • 项目越大，AI 从代码探测出完整上下文的成本越高：10 个文件的项目 AI 扫一遍就理解，200 个文件的项目扫完上下文也耗尽了
• • 训练集少的任务表现不好：AI 本质是通过大数据训练的概率机器，特别新/特别老的技术训练集不够，生成的代码质量差

AI Coding的解决思路

核心就两件事：

1. 1. 维护好上下文信息：把大任务按架构拆成小任务，每个任务 + 解决任务所需的相关信息刚好在 Agent 的上下文窗口内能完成
2. 2. 建立反馈闭环：高效使用 coding agent 的关键在于闭环——它必须能自己测试、自己 debug还有一个和AI开发无关但也很重要：备份。 只要好使了就立即备份，一旦AI改坏了就回退重来。

速度提升带来的新问题

传统开发中 coding 是最耗时的环节，需求讨论和方案设计占比不大。AI 让编码速度大幅提升，coding 不再是瓶颈，但这反而带来了一组新的问题：

• • 互动频繁导致虚假进展：和 AI 协作时反馈很快，会让人觉得进展神速，但回头一看可能一直在原地杵。瓶颈从编码转移到了沟通和决策
• • 范围蔓延：AI 改起来太快，看到不合适的地方就想改，导致颠倒主次。必须明确需求边界，所有非本次迭代的问题都放到需求池
• • 啥也不管只想怼效果：极端情况下不想管细节只想出效果，往往空耗 token。必须退回到"先规划、后执行"

这几个问题核心是做好迭代/版本管理，不在本次讨论范围内。

AI 开发的两种范式

Agentic 模式（自主代理）

给定目标后 AI 自主规划、执行、验证，人只看最终结果。

核心前提：必须有足够的自动化测试覆盖。 AI 生成代码后通过自动化测试验证，测试不通过则 AI 自主修改，形成闭环。没有自动化测试覆盖，这个闭环就无法建立，Agentic 模式就不成立。

Copilot 模式（副驾驶）

人主导决策，AI 执行具体任务，人在关键节点审批。

如果没有自动化测试覆盖，只能走 Copilot 模式。

选择建议

不是非此即彼。根据项目的测试覆盖情况选择：

Copilot 模式的解决方案

固化流程方案：GSD / BMAD / Spec-Kit / SuperPower

这类方案的核心思路是拥有整个流程：从需求到交付，每个环节都由框架控制。

• • 优点：流程自动化程度高，开箱即用
• • 缺点：太重了。固化流程剥夺了你的控制权，流程本身的 bug 难以调试和绕过。如果你的项目或团队情况和框架假设的不一致，适配成本很高

轻量 Skill 方案：Matt Pocock Skills

Matt Pocock 的 Skills 体系 代表了另一种思路：小、可组合、可适配，不拥有流程而是增强能力。

核心理念：

• • 不拥有流程：不替你决定先做什么后做什么，只提供能力
• • 可组合：每个 Skill 解决一个问题，按需组合使用
• • 适用于任何模型：不绑定特定模型或工具链

解决的四个常见问题：

其他类似方案如 Planning-with-files，纯文件驱动的规划执行，也是一个好选择。

补一个题外话： 有很多skill采用了三省六部制的思路，但版本答案（codex/claude)一致的没有采用这种做法，所以对这种效果存疑。

我的最终选择

借鉴 Matt Pocock 的 Skill 思路，基于 opencode 自建 Skill 体系，而非直接采用 Matt Pocock 原版。

为什么不直接用 Matt Pocock 的 Skill？ Matt Pocock 的 Skill 采用的是敏捷开发模式，关注的重点是 user story（用户故事），而不是实现细节——实现完全交给 AI。这对 Opus / GPT 系列模型没问题，模型能力强到只说需求就能给出靠谱的方案和代码。但对目前的国产模型效果不好，国产模型做不到"只说需求不给方案"。因此我在他的 Skill 框架上做了改造：保留轻量、可组合的设计理念，但在 spec 中要求人给出明确的技术方案，AI 按方案编码，而不是让 AI 自己想方案。

此外选择 Skill 而非 GSD 类固化流程方案的原因：我希望增强我的能力，而不是困在流程中。

国产模型能力限制导致了一个关键策略差异：

人必须负责的工作

人的职责由两个因素共同决定：

简单说：人负责"想清楚要什么、怎么实现、最终对不对"，AI 负责"按文档执行编码"。

要解决的两个核心问题

问题一："从需求到交付"

spec 驱动开发，但不是回到瀑布模型的 spec。我花一两天写一个 spec，AI 坑次坑次跑 24 小时产品就出来了——这不现实。没做过你怎么知道自己想要什么？构建的过程会反过来塑造想法，这是一个循环，就像爬山，不是直线上去而是绕着走。

所以 spec 是"先想清楚再动手"的工具，在执行过程中可以迭代调整。（PS: 这也是我没有选择特别重的spec-driver-development skill的原因）

问题二："交付后的长期维护"

功能交付后进入维护期，后续改 bug、加功能、重构都是新会话，AI 又要从零理解模块。解决方案是为每个模块维护结构化文档，作为 AI 的长期知识载体。

两个问题覆盖了项目的完整生命周期：

我的 Skill 体系

各 Skill 简介

辅助 Skill：

注: skill本身具体的内容反倒不重要,现在AI自己就可以写skill,我也是一边用以便根据使用反馈来修改skill,重点是要适合自己的工作流程

组合流程

整体是 8 步工作流，根据场景不同，to-spec 的模式有差异：

场景 a：从 0 到 1 开发新模块（to-spec new）

新模块的完整开发流程，从空白开始。

场景 b：已有模块小更新（to-spec patch）

对已有模块进行小的修正或补充，比如修一个接口字段、增加一个校验规则。

场景 c：已有模块重大变更（to-spec extend）

为已有模块新增一个有意义的独立功能，需要完整的方案设计和独立的 spec。

模型分工

方案设计和 review 阶段需要更强的能力，因此引入 master agent 和 sub agent 的分工：

执行原则

• • 先规划后执行，但不是瀑布模型的 spec，是迭代的
• • 小步快跑，干净的进干净的出
• • 经验教训带触发条件，让 AI 能模式匹配
• • 文档维护成本真实但可控：触发式更新、AI 辅助维护、完成后清理迭代计划

会话管理策略

• • 上下文消耗不超过 80%：AI 会话超过一定长度后智商会下降、响应速率也会下降。因此一个会话用到 80% 左右就应该通过 handoff 交接给新会话继续，避免在低效状态下空耗 token
• • 干净进干净出：一个会话完成完整的N个issue，而不会是半截的issue
• • handoff 交接：当单个会话上下文过长或需要切换场景时，将当前会话压缩为交接文档，下一个会话接续工作
• • 不同阶段用不同模型：方案和 review 阶段用高级模型（master agent），编码执行用日常模型（sub agent）

三个场景的对比总结