从管理工程师团队到管理AI团队，我发现自己最需要的不是新工具，而是一份30页的规格书。

导语：当AI能轻松生成代码，构建系统的真正瓶颈回到人身上：你能否把模糊的直觉翻译成明确的规则？本文记录了一位科班计算机从业者，在AI时代重读《代码大全》的实践与反思。

今天下午，我的交易决策辅助系统 v0.1 跑通了第一个完整的决策流。

它不炫酷——没有华丽 UI，没有自动下单，数据源还是本地 SQLite。但它做到了我最关心的两件事：

1. 每一次决策都有据可查
   
   ——三情景推演、概率评分、移动止损逻辑，全部可回溯。
2. 每一个弱点都无处可躲
   
   ——系统会自动捕捉“贪心事件”、“临近风控线”，让我无法再用“记不清了”来搪塞自己。

看着屏幕上那个朴实无华的 Web 面板，我突然意识到一个问题：这套系统能够被做出来，最关键的变量不是 AI，而是我在动手之前做了那件事——写了一份 30 页的规格书。

而支撑我写出这份规格书的能力，并非来自任何一门技术课程，而是来自一本我反复读过、却一度觉得“太老了”的书——《代码大全》。

作为计算机科班出身、拥有理学士学位的我，曾经带领过工程师团队，现在又和AI团队（大模型、Agent）打交道。这种转变让我不断反思：管理人类工程师时，最头疼的是“需求不清”；管理AI团队时，最头疼的依然是“需求不清”。

今天，我想认真聊聊这件事：在AI深度介入编码的2026年，一本1994年首次出版、讲“如何写代码”的书，对我这样的科班出身的系统构建者，到底意味着什么。

当时大家是怎么理解这个问题的

回顾整个系统的开发过程，我发现自己经历了一个非常典型的三段式思维。

第一阶段：“找个现成的交易软件用吧。”——发现没有一个软件能理解我独特的交易逻辑。

第二阶段：“AI能写代码了，我直接让它帮我写个交易系统。”——AI给了我一个极其通用的框架，华丽但无用。

这是很多人在AI时代的自然反应：既然AI能生成代码，那我把需求扔给它就行了。甚至不需要我自己想清楚需求，AI会替我补全。 这种想法听起来很诱人，但它隐含着一个致命假设——你的需求是清晰的、结构化的，只是你不擅长写代码。

第三阶段：“不，我要先把自己的交易逻辑写清楚，再做系统。”——我坐下来，用两天时间写了一份30页的规格书。

这个三段式，其实和我过去带团队时一模一样：一开始总想找现成方案，发现不行；然后让工程师直接开干，结果返工；最后逼着自己把需求写清楚，项目才真正推进。只不过现在工程师换成了AI。

为什么这种理解会让事情越做越偏

如果停留在第二阶段，我大概率会得到一个“看起来能跑、但一用就废”的系统。因为AI生成代码的前提是——你足够精确地告诉它你要什么。而大多数人，包括我自己，在动手之前根本不知道自己到底要什么。

模糊的需求交给AI，结果是精美的废品。

更深的误区在于：我们把“写代码”当成了构建系统的全部。但软件构造的核心从来不是编码，而是 管理复杂度。

AI可以替你完成编码这个“体力活”，但它无法替你完成最艰难、也最本质的工作——把模糊的、直觉性的认知，翻译成精确的、结构化的、可执行的规则。

这个翻译过程，就是《代码大全》全书的核心思想：软件构造的本质是“管理复杂度”，而管理复杂度的唯一方法是“系统性地把混乱转化为秩序”。

当时我缺的，不是AI工具，而是这套管理复杂度的思维框架。即使我有计算机学位，即使我带了多年工程师团队，在没有这个框架时，面对交易这种非线性系统，我依然会陷入“直觉-尝试-失败”的循环。

我的核心判断

在AI已经能写出生产级代码的今天，理解软件构造的本质，比掌握任何一门编程语言都重要。

因为构造的本质是管理复杂度，而管理复杂度的背后是结构化思维。这种思维不依赖工具，不依赖语言，只依赖你能否把一件事说清楚、写明白、分得开。

《代码大全》讲的就是这个东西。它用数百页的篇幅告诉你：什么是好的变量命名、为什么模块化重要、怎么处理错误、怎么设计测试……这些在今天看来依然有效，因为复杂度不会因为AI的出现而消失，只是转移了。

转移到了哪里？转移到了需求定义、架构决策、质量判断上。而这些，恰恰是《代码大全》里花最多篇幅讲的内容。

具体怎么做

决定写规格书之后，我花了整整两天时间，把自己关在房间里，用Markdown记录我的交易逻辑。

这个过程非常痛苦。因为我发现自己根本说不清楚：

• 什么是“趋势”？价格在MA20之上且斜率向上，算趋势吗？回调多少算回调，多少算反转？
• 什么是“关键位”？支撑和压力怎么定义？是前高前低，还是均线交叉点？
• “风险偏好”如何量化？什么情况下该加仓，什么情况下该减仓？

这些问题，没有一个标准答案。但《代码大全》教会了我一个核心原则：没有什么比“模糊的定义”更能摧毁一个系统。 所以我不追求“正确的定义”，我追求“明确的规定”。

于是我在v0.1里定义了一套非常简单的规则：

• 趋势：价格在MA20之上且MA20斜率向上 → 多头趋势；反之空头。
• 关键位：最近20根K线的最高/最低点。
• 风险：每笔交易亏损不超过本金的2%。

不完美，但可执行、可迭代、可复盘。

写完规格书后，我把其中的规则发给AI，让它生成对应的代码。这次输出的代码不再是通用框架，而是完全贴合我的逻辑。几小时内，v0.1就跑起来了。

一个真实场景

这件事让我联想到过去带团队时的场景：有个项目，业务部门说要做一个“智能报表系统”。他们和工程师开了三天会，工程师写了两周代码，交付后发现全是错的。业务部门说“这不是我要的”，工程师说“你们当时就是这么说的”。

我当时的做法和现在一样：要求业务部门写一份“报表规格说明书”。定义清楚字段来源、计算逻辑、更新频率、输入输出。这份文档后来成了整个项目的“宪法”，后续开发几乎没有返工。

现在和AI团队合作也一样：我发给AI的不是“帮我做一个交易系统”，而是一份完整的规格书，包括业务规则、数据模型、边界条件、异常处理。AI在几分钟内就生成了一份可运行的代码，而且非常贴合需求。

规格书就是我和AI之间的“合同”。合同不清晰，执行必然走样。

收束

《代码大全》出版至今已经超过25年。书里的技术栈早已过时，很多工具和语言已被淘汰。但它的核心智慧——管理复杂度、结构化解构、系统化构建——在AI写代码横行的今天，不是过时了，而是从未如此重要。

在所有人都能轻易“生成”代码的时代，你能否“构造”出一个经得起时间考验的系统，将取决于你是否理解构造本身。

而我，选择用一本25年前的书，来帮我打好这个底。

如果这篇文章对你有启发，欢迎交流你的场景。

下一步，我会把交易系统v0.1的规格书做一些脱敏处理，整理成一个专栏公开部分核心思路，包括：

• 非程序员怎么从零开始写一份“可交付给AI”的规格书？
• 交易中那些“模糊的经验”，如何翻译成“可执行的规则”？
• v0.1到v1.0的迭代逻辑，避坑指南。

这不是教程。这是我在AI时代，给自己建立“主权系统”的过程。希望能给你一些启发。

标签：AI / 代码大全 / 系统设计 / 交易系统 / 结构化思维 / 项目管理