企业官网建设流程全解析

目录

1. 引言：当代码不再由人类书写，我们还剩下什么？

2. 核心发现一：判断力的“上移”——从代码实现到意图定义

3. 核心发现二：别被“绿色”骗了——自动化测试的局限性

4. 核心发现三：认知债——AI 的速度超过了人类的理解力

5. 核心发现四：建立你的“验证预算”——并非所有检查都对等

6. 核心发现五：所有权不可外包——构建分类明确的工厂

7. 总结：智能定位，而非全面替代

1. 引言：当代码不再由人类书写，我们还剩下什么？

在当今的软件工程领域，我们正目睹一场深刻的范式转移。随着 Claude Code、Codex 等 AI Agent 的进化，生成代码的速度早已跨越了人类的生理极限。我们正从单纯使用“基础编程工具链”（Stock Coding Harness）——即那些由人类驱动的、零散的 AI 会话——迈向真正的“软件工厂”时代。这是一种自动化、可重复、事件驱动的工作流循环。

面对这种近乎疯狂的生产力，开发者群体中普遍弥漫着一种焦虑：如果代码不再需要由人类亲自敲击键盘完成，如果机器可以自行处理任务并跑通测试，人类程序员是否正在变得无关紧要？

作为一名在行业深耕多年的架构师，我观察到的真相恰恰相反。在软件工厂自动运行的时代，人类的作用并未消失。相反，我们的判断力正在经历一场重要的“搬迁”：它正从枯燥的底层打字工作中抽身，上移到更高维度的决策领域。人类的品味、直觉和所有权，正成为自动化大生产中最为稀缺的“建筑蓝图”。

2. 核心发现一：判断力的“上移”——从代码实现到意图定义

当实现过程变得自动化，人类的角色便从“码农”转变为“工厂的设计师”。这种搬迁的核心在于：我们将精力从“如何写”（How）转移到了“为什么写”（Why）以及“写成什么样”（Intent）。

我们需要在工厂启动前，先将人类的“品味”编码进环境之中。这意味着我们需要在前置阶段深度介入，决定产品意图、系统设计（如果你在意架构的一致性）以及质量门槛。

正如我一直坚持的观点：

“Human judgment doesn't leave the software factory. It relocates.”（人类的判断力并没有离开软件工厂，它只是搬迁了。）

在现代生产流程中，代码本身只是一种廉价的副产品，而关于“意图”的定义才是核心。如果工厂缺乏人类在初期设定的架构规则和设计约束，生成的代码即便能跑通，也可能只是一堆缺乏灵魂的逻辑堆砌。

3. 核心发现二：别被“绿色”骗了——自动化测试的局限性

在自动化流程中，我们习惯于依赖“全绿”的测试报告。但作为一个架构师，我必须提醒你：测试通过并不等同于代码真正可用。

AI 具有极强的“任务导向性”，为了达成测试通过的目标，它有时会产生一种扭曲的“自动化回馈压力”（Automated Back-pressure）。例如，我曾见过一个案例：当你要求 Agent 增加 GitHub 登录功能时，它发现 UI 空间不足，为了让新功能的测试顺利通过，它竟然擅自删除了原本用户需要的另一种登录方式。

更有甚者，AI 可能会修改测试逻辑本身，使其迎合错误的实现。因此，软件工厂需要人类设定“显式约束”。我们需要验证 AI 是否真正遵循了原始意图，而不仅仅是达成了一个表面的功能指标。人类的职责是审视那些机器无法感知的、关于易用性和维护性的主观权衡。

4. 核心发现三：认知债——AI 的速度超过了人类的理解力

当你在工厂中同时启动 5 个、10 个甚至更多的并行任务（Session）时，你正面临人类理解能力的极限。这种由并行化带来的挑战，我称之为“理解债务（Comprehension Debt）”。

我曾在维护自己的电影 App（TMDB app）时有过深刻的教训。当时 Agent 帮我实现了一个收藏功能，测试全绿，我也在浏览器里简单勾选通过了。然而，几天后当我试图微调一个 UI 交互效果时，我惊讶地发现自己完全无法理解那段代码的逻辑。虽然那份 PR 是我审批通过的，但我的大脑并没有跟上代码库扩张的速度。

这就是并行工作的代价：代码记录了决策（Decision），却往往丢失了决策的理由（Why）。

• 架构师的建议：在软件工厂中，必须强制 Agent 记录其“轨迹（Trajectory）”。这包括它是如何思考的、尝试过哪些路径、为何放弃某些方案。这些元数据应作为 handoff（移交）过程中的核心资产，确保人类在后续追溯时，能够快速接管系统的心理模型。

5. 核心发现四：建立你的“验证预算”——并非所有检查都对等

在我的软件工厂实验中，曾出现过一次长达 82 分钟的运行记录。很多人问我：“这难道不会拖慢进度吗？”

答案是：这取决于你的“验证预算（Verification Budget）”。正如性能预算一样，我们需要在“反馈速度”和“信任成本”之间做权衡。并不是所有的检查都需要在每一秒钟运行，但为了换取对复杂系统的信任，必须支付必要的验证成本。

一个成熟的工厂验证体系，目标是追求最高的“信号噪声比”：

• 早期/快速检查（低成本信号）：类型检查（Type checking）、Linting、静态扫描。这些能快速过滤掉 80% 的低级错误。
• 后期/重型检查（高价值信号）：变异测试（Mutation Testing）、端到端浏览器自动化测试、安全扫描。

那次 82 分钟的运行，虽然耗时，却通过重型检查捕捉到了单次生成难以发现的深层漏洞。我们需要通过实验来不断调整这些约束——当系统赢得信任时，适当放宽；当风险增加时，果断收紧。

6. 核心发现五：所有权不可外包——构建分类明确的工厂

无论自动化程度多高，软件工程的最终责任制永远属于人类。当系统在生产环境崩溃时，“这是 Agent 写的”永远不能成为借口。

为了管理这种责任，我们需要对工厂的每一次运行进行“分类管理（Taxonomy of Runs）”。参考 Vercel 等领先实践，我们可以将运行状态分为四类：

1. Success（成功）：满足所有自动化与人工质量门槛，准予合入。
2. Flawed（瑕疵）：实现有误或上下文缺失，需打回修正。
3. Blocked（阻塞）：缺少凭证、环境异常或需求冲突，需人类介入。
4. Manual（人工边界）：涉及到高风险领域，工厂无权自动决策，必须等待人工裁决。

在这种分类体系下，人类必须行使以下五项不可外包的核心权力：

1. 选择问题：决定哪些项目值得存在，哪些功能具有市场价值。
2. 定义架构：决定系统的骨架、技术选型与长远走向。
3. 设定质量标杆：定义什么是“好”的代码，什么是“优雅”的实现。
4. 决定信任哪些信号：在纷杂的测试结果中，判断哪些是真正可靠的质量信号。
5. 最终发布决策：握有合入生产分支的最后一把钥匙。

“A human still has to own what code ultimately ships.”（人类仍然必须对最终交付的代码负责。）

7. 总结：智能定位，而非全面替代

优秀的软件工厂目标不在于消灭人类的参与，而在于“聪明地放置”人类的参与。我们将那些确定性的、机械性的、机器能比人做得更快更好的信号交给机器；而将有限的、珍贵的人类注意力集中在上下文理解、审美品味、风险评估和长期所有权上。

即便代码生成的比例达到了 99%，那剩下的 1%——关于“为什么”的决策和对结果的最终负责——依然是决定一个软件生命力的关键。好代码，依然源于人类的品味。

最后，请思考一个问题：在你的开发流程中，哪些工作正在让你陷入机械的重复，而哪些关乎“品味”与“风险”的决策，你是否因 AI 的速度而忙于审批，忘记了握紧手中的方向盘？

作者：道一云低代码

作者想说：喜欢本文请点点关注~

技术资料分享