/tags/ai-coding/ Recent content in ai-coding on Hugo -- gohugo.io en Thu, 21 May 2026 22:00:00 +0800 /reading/martinfowler/structured-prompt-driven-spdd/ Thu, 21 May 2026 22:00:00 +0800 /reading/martinfowler/structured-prompt-driven-spdd/ 背景：我为什么会去读这篇 整理 Agentic Workflow 那篇笔记时，我反复卡在同一个问题上：**当 AI 真的开始替我写代码，“需求"和"设计"这两件事到底应该长成什么样？**Spec Kit、AGENTS.md、ADR 都能算是答案，但它们各自只覆盖了一部分。 正好在 Martin Fowler 的网站上看到 Wei Zhang 和 Jessie Jie Xia（两位都来自 Thoughtworks）2026-04-28 发的这篇 Structured Prompt-Driven Development。文章的核心主张比较干脆：把 prompt 当成与代码同级的工程工件管理——版本化、评审、复用、迭代。 这条主张其实不新，但作者把它具体化成了一组流程、一份七维度模板和一套配套 CLI（gszhangwei/open-spdd），加上一个完整示例项目（gszhangwei/token-billing），值得花时间读完整理。 关于 SPDD 与 PDD、Spec Kit、PromptOps 这些相邻概念的差别，我另起了一篇速写：prompt-driven vs spec-driven：把 PDD、SPDD、Spec Kit 几支理清楚。本文只聚焦 SPDD 这一篇文章本身。 这篇文章不是教程，是我读完后留下的几条笔记 + 对照我自己经验的取舍判断。 文章主张：prompt 是一级交付物 文章开头给的一句话很直接： Instead of relying on ad hoc chats, SPDD turns prompts into assets that can be: version controlled, reviewed, reused, and improved over time. /posts/agentic-workflow-engineering-2026/ Sun, 26 Apr 2026 15:30:00 +0800 /posts/agentic-workflow-engineering-2026/ 背景 最近几个月我翻了几份团队内部和合作方写的「AI 辅助开发流程」文档，也在不同项目里反复用了 Claude Code、Codex CLI、Cursor。到目前为止，一个让我印象比较深的现象是：在我接触到的不少团队里，「AI 辅助」仍然更接近 2024 年常见的"对话框 + 复制粘贴"模式——人手动把 PRD、Tech Design 模板、代码上下文一次次拷进 Prompt 框，AI 输出一段文本，人再贴回 Confluence 或 IDE。 而同期一些更早公开分享这类实践的团队，做法已经不太一样： Anthropic 的公开文章展示了多个团队如何把 Claude Code 用到 code review、排障、代码导航等具体场景里（原文）。 Rakuten 的案例文章给出了一组公开数据：TTM 从 24 个工作日降到 5 天，最长一次连续自主编码 7 小时；这些数字来自其官方案例分享，更适合当作参考样本，而不是直接当成通用基线（原文）。 Bessemer Atlas 对 Shopify 工程负责人的采访提到，Shopify 允许 Claude Code、Copilot、Cursor、Codex、Gemini 等工具并存，并用自建 LLM Proxy 做统一接入与治理；这更像一次访谈里的组织实践样本，而不是完整方法论（原文）。 我理解这两种使用方式之间的差距，未必只在于"AI 用得熟不熟"，更像是软件开发流程的工程化程度——前者很多时候还得靠人脑当编排引擎，后者则开始把一部分编排交给 agent，把一部分规则交给 ArchUnit / Hooks / GitHub App。 这篇文章不打算给一份"最佳实践"。模型能力、工具协议、商业模式都在快速演化（Claude 4.x、MCP、AGENTS.md、Spec Kit 都是 2024 下半年到 2026 年初才逐步稳定的），太早收敛到"标准答案"反而可能束缚团队。我更想做的是：把现实项目里的困惑和当下能看到的公开实践对齐，整理一份自己后续继续学习和落地时会反复回看的方向清单。 后续落地的细节会另起一篇，先把方向理清。 Agentic 与「贴 Prompt」的真实差距 「AI 辅助开发」是一个被严重过载的词。要把后面的讨论建立在共同语境上，先把两种使用模式区分清楚。