/tags/team-workflow/ Recent content in team-workflow on Hugo -- gohugo.io en Sat, 23 May 2026 23:30:00 +0800 /posts/keeping-features-out-ai-era-2026/ Sat, 23 May 2026 23:30:00 +0800 /posts/keeping-features-out-ai-era-2026/ 背景：一篇 InfoWorld 的文章让我想起的事 刚看完 Nick Hodges 在 InfoWorld 上 2026-04-29 发的 A new challenge for software product managers。文章不长，核心就一句话： It used to be the hard part was jamming in that extra feature. Now? The hard part will be keeping them out. 作者的论点是给 PM 的：以前 PM 要争时间、争资源把 feature “塞"进版本，现在 agentic AI 让一个 feature “morning conceived, afternoon shipped”——backlog 这个本来给 due diligence 留缓冲的东西也跟着塌缩了，PM 的难点从"怎么加"反转成了"怎么挡”。 但我读的时候一直在想另一件事：这件事不只是 PM 的难题，工程师其实是被同一股压力波及的，而且我们过去赖以否决 feature 的最强武器，正好就是被 AI 拆掉的那个。 这篇是顺手写的延伸笔记，把 Hodges 那个反转放进工程师这一侧再看一遍。不是反驳——我同意他的判断——只是想说，“挡 feature"这个新责任如果只压在 PM 身上，通常挡不住。 /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 年 4 月前后仍在快速变化的东西），太早收敛到"标准答案"反而可能束缚团队。我更想做的是：把现实项目里的困惑和当下能看到的公开实践对齐，整理一份自己后续继续学习和落地时会反复回看的方向清单。 后续落地的细节会另起一篇，先把方向理清。 Agentic 与「贴 Prompt」的真实差距 「AI 辅助开发」是一个被严重过载的词。要把后面的讨论建立在共同语境上，先把两种使用模式区分清楚。