我的 AI Coding 工作流：一次给团队的个人分享

Aug 27, 2026 — AI , Agents , Skills , Context Engineering , Automation , Software Engineering

最近在团队内部做了一次分享，主要是有关我个人是如何使用 AI Coding 的，供大家参考一下。

一开始我只想整理一下自己现在用哪些工具，平时怎么让 Agent 写代码。写着写着才发现，工具只是表面，往后还有 Context、Skills、Runtime、本地产物、验证、多 Agent 和 Automation，一篇文章根本装不下，原稿也越写越长，最后拆成了四篇。

回过头来看，自己的使用方式一直变个不停，紧跟着模型能力的升级而进化。早期用 AI，更多是问 API、解释报错、补一段代码。现在经常把完整任务交给 Coding Agent，让它读仓库、查调用关系、修改代码、跑测试、看浏览器或真机结果，再根据证据继续处理。

任务一长，问题也跟着变了。模型会不会写代码当然重要，但平时更容易出错的地方，经常是上下文给错、工具拿不到真实状态、长任务中断后接不起来、Skill 用得太重，或者 Agent 说“完成了”，手上却没有足够证据。

这次分享主要想梳理的就是这些问题，以及我现在怎么处理它们。

它只是我当前个人开发环境的一张快照，不是团队规范。模型、Coding Agent 和 Runtime 还在快速变化，具体工具以后肯定会换。真正值得留下来的，是那些在真实项目里反复出现的问题，以及目前对我有效的处理办法。

工具篇

工具篇先从日常工作台讲起。

里面记录了我现在常用的 ChatGPT / Codex、Pi、CodeGraph、Context7、Chrome DevTools MCP、终端工具，以及哪些重复工作已经交给 Automation。

我现在选工具时，越来越少比较“谁的功能更多”，更关心它能不能拿到当前任务的真实状态，包括代码、Git、测试、浏览器、真机和日志，这些信息能不能直接进入 Agent 的反馈循环。能解决这个问题的工具，我才会长期留下来。

Skills 篇

Skills 日常工作流篇是这次调整最多的一篇。

我以前很容易把 Skill 设计成一条完整流水线，wayfinding -> grilling -> to-spec -> high-level-design -> quick-implement -> simplify -> code-review 一路走到底。真实项目里用久以后，这种设计越来越别扭，一个很小的修改也被迫走流程，需求已经清楚还要重新探索，Runtime 已经有 Goal 和 resume，Skill 又套一层自己的生命周期。

现在的做法简单很多，先看当前还缺什么，再选负责这个阶段的 Workflow，debug、tdd、simplify、code-review 这些 Engineering Discipline 按实际问题叠加。长任务则靠 MAP.md、SPEC.md、按需的 HLD.md、tickets 和 evidence 这些本地产物保存关键事实，不把所有状态都堆在一条越来越长的聊天记录里。

Agent 学习篇

我学习的目的不是一定要成为Agent开发，只是遇到不懂的就问 AI，了解这些内在原理，对我使用 Agent 工具会更有帮助。所以，Agent 学习篇记录的是这些概念怎么一点点补起来。

我的学习方式没有系统化，算是比较工程化吧，先在项目里碰到问题，再回头找对应机制。Agent 忘了前文，才认真研究 Context 和 Memory。长任务会中断，才去理解 Runtime、Goal 和 Harness，多个 Agent 一起得出错误结论，才开始关心 context isolation 和 independent review。

最后串起来的大概是 Model、Context、Tool、Harness、Runtime、Skills、Memory、多 Agent 和 Automation。这个顺序谈不上课程大纲，只是实际踩坑以后留下的一条学习路径。

感悟篇

感悟篇不再讲具体工具，主要记录这一年反复遇到、目前仍然认可的一些判断和思考。

比如遇到 Agent 表现差时，我会先检查 Context，再考虑改 Prompt。Runtime 和工程环境会直接影响模型能力能不能稳定发挥，多 Agent 真正有价值的地方往往是独立性，Automation 更适合边界稳定、结果可检查的工作，Agent 的自我汇报不能替代真实证据。

还有一个感受越来越明显，代码生成越快，人的判断越需要慎重。

AI 把实现速度抬高以后，需求是否值得做、改动边界是否合理、证据是否充分、维护成本能不能接受，这些事情并不会自动变简单。

整理这些博客之前，我脑子里已经有一套工作习惯，只是很多东西散落在 AGENTS.md、Skills、自动化任务和日常对话里。真正写下来以后，哪些属于长期原则、哪些只是当前工具的能力、哪些地方已经设计过度，反而更容易看清楚。

现在遇到一个新任务，我会先问几个很实际的问题，当前最大的未知是什么，这个任务真的需要 Skill 吗，哪些信息值得写进本地产物，Runtime 已经负责的事情还要不要再造一层控制，最后拿什么证据判断任务完成？

这四篇记录的是我在 2026 年 8 月的答案，以后工具和做法还会继续变，过一段时间再回头看，大概又会有不少地方需要重写。