> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2026-nian/w38-wan-wu-jie-ke-gong-cheng-hua.md). # W38-万物皆可工程化 最近做的几件事，让我越来越强烈地感到，AI 正在改变我处理复杂问题的方式。 以前，一个问题复杂到一定程度，我通常只能投入更多注意力。记住配置，维护文档，反复解释背景，出错后再排查。即使知道可以写程序解决，也未必值得为它搭建和维护一套系统。 现在，我更愿意把它变成一个工程。 把事实和规则写下来，把重复操作交给程序，为变化增加验证，保留历史和回退路径。以后遇到新需求，就在这个基础上继续扩展。 工程化的方法早就存在。**AI 降低了实施和维护这些方法的成本，让许多过去不值得做的工程，现在值得做了。** ## 从代理配置到一个可以维护的工程 第一个例子是我的 Mac 代理配置。 最初，这只是让几个应用正常联网的问题。随着需求增加，它逐渐涉及不同网站的分流、公司网络直连、命令行与桌面应用的环境差异，以及配置更新和设备迁移。 每次单独处理都不算难。但这些规则叠加以后，很难仅靠记忆维护。今天解决一个问题，过一段时间，可能已经忘了为什么要这样配置，也不知道下一次修改会影响哪里。 我后来把这套方案整理进了一个私有仓库。 仓库里有配置模板、分流规则、生成和校验脚本，也有恢复、维护和排障手册。修改之前可以预览，安装之前可以备份，出了问题有回滚路径。迁移到另一台 Mac，也有明确的步骤和验收要求。 我已经在另一台电脑上完成了实际迁移，验证了这套方案的有效性和效率。原来需要逐项排查、手工配置的过程，现在可以按照仓库里的规则和流程完成。这个工程也因此有了经过实测的复用能力。 对我而言，变化在于，我终于能把这套配置当作一个长期维护的系统来处理。增加一个应用或调整一条规则时，有地方修改，有方法验证，也能查清过去做过什么。 **复杂度仍然存在，但它有了明确的存放位置和处理方式。** ## Agent Team 本身也需要工程化 第二个例子，是我运行了一段时间的 Agent Team。 一个人工作时，如果只用一两个 Agent，直接对话、分配任务，通常就够了。 但当我需要多个 Agent 分角色处理不同的事情，并让它们自行组织、协作解决复杂问题时，就需要一套明确的运行规则。 谁来拆解任务，谁负责实现，谁负责评审，任务如何交接，遇到问题由谁接手，都需要事先安排。给团队或工程增加自动化任务后，还要管理这些工作如何触发和运行。比如自动查找代码变更并做 PR review，或者在集成仓库合入后，自动将对应内容投影到各个子仓库。 这些需求逐渐超出了手工维护几份提示词的范围。于是，我把 Agent 的角色配置、协作规则和自动化任务整理成了一个可以管理、运维和持续扩展的工程。 角色职责、协作规则和运行策略都保存在仓库中。仓库声明团队应该是什么状态，同步工具负责检查它与运行状态之间的差异。修改可以先预览，应用后再核对是否一致。 这让我可以持续调整团队，而不必每次都重新拼装一遍。 **一次有效的协作经验，可以变成所有相关角色共同遵守的规则。** 一次失败暴露的问题，也可以进入配置和验证流程，成为下一次工作的基础。 我开始把 Agent Team 当作一个需要运维和迭代的系统。模型能力是其中一部分，角色边界、任务交接和验收方式同样需要持续改进。 ## 把团队的工作上下文放进同一个版本 第三个例子，是正在进行中的报税 MVP。 我们在 BFO 的集成仓库里推进这个项目。产品与架构文档、接口契约、验收规格、前后端代码和 Agent 工具，都进入同一个集成仓库，形成共同的版本基线。 **我想实现一种文档即代码、代码即产品的工作方式。** 产品规则发生变化时，相关文档、契约、实现和验收标准可以一起修改、一起评审。我们能够回到某个版本，查看当时的要求是什么、代码如何实现、用什么标准判断它做对了。 过去，这些上下文往往散落在文档、聊天记录和不同人的记忆里。跨角色协作时，需要反复搬运和解释。产品讲一次，研发理解一次，测试再还原一次。需求变化之后，还要重新确认每个人拿到的是不是同一个版本。 集成仓库让这些工作有了共同的依据。 它不能消除人与人之间的理解差异，但可以减少寻找资料、核对版本和重复解释背景的成本。讨论可以围绕具体变更展开，结论也有明确的地方沉淀。 AI 同样可以读取这些材料。接到一个任务后，它能够沿着需求、契约、实现和测试查找上下文，而不必完全依赖当前对话里临时提供的信息。 这个 MVP 还在进行中，长期收益尚待验证。但我尤其看重后续的日常迭代。只要这些资产随着产品一起维护，每一轮工作就有机会为下一轮留下更完整的基础。 **以前做过的工作，能够继续降低未来工作的成本。** ## 财务管理中的事实与表达 第四个例子还没有实现，是我计划中的个人财务与投资管理工程。 目前，我在 Google Drive 中维护家庭财务相关的每周、每月和每季度审查材料，也在持续做市场观察。 我准备把这些工作逐步整理进一个私有工程。包括家庭财务的基本情况、投资标的、投资渠道、市场观察，以及定期审查的记录。 **这里最吸引我的，是可以把事实源和表达方式分开。** 过去，当我决定用表格、文档还是 PPT 记录信息时，往往已经在考虑它最终应该长什么样。数据的组织方式，很容易被展示工具决定。 以后，我希望先维护一份有来源、有时间、有版本的基础记录，再根据具体问题生成表达。 想看资产结构，就生成图表。想做月度审查，就生成报告。想了解某项变化，就沿着历史记录追问。不同的呈现都来自同一份基础数据，也都能回到它核对。 这样，我就不需要为了每一种表达重新整理一遍事实。图表和报告可以随时生成、调整，长期维护的重点则是底层信息是否准确、完整、及时。 这也是我理解工程化的一次变化。工程里可以承载事实、规则和决策记录，再按需要生成供人阅读和使用的界面。 ## AI 让工程化的投入更容易收回来 这几个案例有一个共同点。它们都积累了一定复杂度，也都需要持续维护。 过去，我未必愿意为它们建立工程。写脚本、补文档、做验证、维护工具，都需要投入。很多个人需求规模太小，收益不足以覆盖成本，最后只能继续手工处理。 AI 降低了这笔投入。 当整理配置、编写脚本、补充测试和维护文档变得更便宜时，我愿意用工程方法处理的问题就更多了。代理配置、Agent 协作、团队工作上下文，乃至家庭财务，都开始进入这个范围。 **可靠性仍然需要具体机制支撑。** 事实要核对，变更要验证，失败要能被发现，必要时要能回退。AI 可以帮助建立和维护这些机制，但不能替代它们。 有了这些基础，我才更有把握继续增加能力。**系统能处理的问题变多，也不必要求我按同样的比例增加记忆和注意力。** 我现在有一个越来越清晰的判断，万物皆可工程化。 更准确地说，**只要一个问题中有可以明确描述、计算和验证的部分，我就有机会把它组织成一个可以持续维护的工程。** 判断和取舍仍然由人承担，但围绕它们的信息整理、执行和反馈，可以不断改善。 以前面对复杂问题，我首先想到要投入多少精力。现在，我会先想，能不能为它建立一个以后还可以继续生长的系统。