Imprint 如何实践 Software Factory 模式
Trying the Software Factory Pattern
在 2026 年的 AI 生态中，新模式的涌现速度远超我的适应节奏。从全员使用 Claude Code，到迁移至 Linear 替代 Jira，再到部署名为 Agent Fleet 的编排系统，Imprint 今年的技术演进可谓波澜壮阔。最近，我开始尝试 Software Factory 模式：通过一个循环机制，让 AI 代理基于 Linear 项目目标、Notion 文档及 Datadog 数据自主审计、规划并执行任务。这种模式不仅让我意识到自己曾无意中囤积了项目状态，还让代理能主动评估方向并补充缺失任务。更重要的是，它在发布后持续监控关键指标，确保问题不被遗漏。这一切的前提是拥有统一的状态源和强大的编排工具，而正是这些组件的叠加，才让 Software Factory 真正发挥作用。
这种工厂模式特别吸引我的地方在于，它与我本地工作方式高度契合，同时迫使我意识到自己曾无意中囤积了关于项目目标的部分状态。
HN 评论区
45- hibikir
Will 在一个相对灵活的机构里都遇到了这些问题，而他在那里对采用什么技术拥有很好的掌控权。想象一下，在那些更加僵化的企业环境中，这会有多“有趣”：要想高效完成工作，往往意味着要在开发负责人和直线管理层的默许下绕过既定流程。个体之间的性能差异从未像现在这样巨大，这不仅仅是生产力的提升，更包括性能损失——一些判断力存疑的人引发问题的速度要快得多。
当一个组织缺乏做出改变所需的“肌肉”，且没有人被授权去确保系统正常运行时间（uptime）良好时，维持质量是一个巨大的挑战。许多东西会崩溃，恰恰是因为变化量与 Will 看到的差不多，但这些变化分布得非常不均匀。
- alexpotato
所以我最终也做了一些类似的事情：
- 为 Issues 创建一个 GitHub 项目看板
- 将 Grok 连接到上述看板
- 使用 Grok 语音模式来记录想法，让 Grok 和我一起完善这些想法，然后将其保存为 Issues
- 在 OpenCode 中创建了斜杠命令，如 /ni（新建问题）、/do（处理问题）、/curr（当前问题是什么）、/done（顾名思义）
- 我通常会告诉 OpenCode 实例执行 /do <数字>，然后它就自己去干了
这给我带来了几点好处：
- 我可以在走路或开车时使用 Grok 语音来开发和测试想法
- 即使我整个本地的 OpenCode 环境都丢了，相关数据依然存在于 Issues 中
- 多台机器可以从 GitHub 读取数据
- 我甚至可以更进一步，为我的每个机器人创建单独的用户账号。
鉴于我曾身兼 PM、开发、SRE 和管理者数职，这确实感觉像是在管理一支开发团队。
- richardbarosky
在公开场合谈论这些事物并把自己置于聚光灯下，这一点非常值得赞赏。向你致敬！
然而，就所追求的方向而言，这看起来更像是在盲目追逐炒作周期，而没有强烈地质疑新软件开发方法端到端的价值，也没有仔细评估其即时的适用性。
就我个人而言，我认为更合理的做法是挑选几个人或几个小团队，进行更孤立/“臭鼬工程”式的实验，然后根据这些人的报告和经验来决定是否采纳。小团队可以更快地调整，迭代并向更大的开发组织提供关于良好方法、技术和策略的建议，从而避免那些考虑不周的事情造成更广泛的损害或混乱。
对于更保守的 AI 用例，比如辅助代码审查、撰写低风险 PR 摘要，或加强安全检查，一种更全局化但仍不至于脱轨的方法，才是值得更广泛推广的方向。
- bsilvereagle
有没有人明确地证明，他们通过采用代理式（agentic）软件开发流程，在市场份额上击败了那些公开表示 _不_ 采用该流程的竞争对手？这篇文章描述了很多流程上的折腾，却没能清晰地说明这些折腾是如何影响功能开发或收入的。
- bicx
我的团队正处于代理编排器（agentic orchestrator）阶段。我在概念上很喜欢这种 Software Factory 模式，但我们在开发中面临的最大挑战是任何与 UI 相关的验收测试。特别是移动应用测试，仍然是一个巨大的瓶颈，需要人工介入。AI 模型在识别糟糕的可用性和卡顿（jank）方面表现真的很差，特别是因为它们通常只处理特定时刻的应用程序快照。
我知道有一些传统的测试框架可以在一定程度上检测抖动（jitter）和掉帧。我们或许可以让代理（agents）开始构建这些功能。
如果每个项目都有具体的设计文档和规范，那也会有所帮助，但在快速迭代的初创公司里，这些通常都委托给了构建者。这又让每次循环都不得不把人类拉回来。
很好奇大家是如何完全采用 Software Factory 模式的。