企业官网建设流程全解析

最近，AI 编码的话题又被推上了一个新高度。这一次的主角不是某个大模型的版本更新，也不是哪家 IDE 插件又出了新功能，而是一位老熟人——Windows 任务管理器之父 David Plummer，以及他打造的 Win11 项目 TMOG。

消息一出，很多人的第一反应是“又一个 AI 编码工具”或者“老程序员来蹭 AI 热度”。但真正值得关注的，是被反复提到的“107 页文档”。它不是产品说明书，也不是 API 文档，而是一份面向大模型的需求描述规范。

换句话说，这次的重点不是“用 AI 生成代码”，而是“如何把需求写到让 AI 能一次说懂”。

本文会把这件事拆开讲清楚：TMOG 背后代表的是怎样一种工程思路，107 页文档到底解决了什么问题，以及作为普通开发者，如何在 Win11 环境下把“AI 编码需求描述规范”真正落地到自己的项目里。

1. 任务管理器之父为什么会盯上 AI 编码

1.1 一个老系统程序员的开发底色

在聊 TMOG 之前，有必要先弄清楚 David Plummer 是谁。

David Plummer 是 Windows 任务管理器（Task Manager）的原始作者。1994 年，他在 Windows NT 开发期间完成了任务管理器的初期版本。今天 Win11 用户按Ctrl+Shift+Esc打开的窗口，依然是这个系统的后代。他在微软工作多年，也在 Windows 图形架构、DirectX 驱动模型等领域有大量底层经验。

后来他离开微软，运营了个人频道 Dave's Garage，长期分享 Windows 98 移植、任务管理器考古、算法题讲解、嵌入式开发等内容。和多数只关注业务开发的博主不同，Plummer 的视角非常“底层”：他会关心一个线程在内核态怎么调度，会关心某个 API 在 30 年前为什么被设计成那样。

这种背景决定了 TMOG 不可能只是一个“封装大模型的套壳工具”。对于写惯了系统级代码的人来说，任何不能精确控制输入输出、不能验证结果的技术方案，都是不可接受的。

1.2 TMOG 真正的信息增量：需求前置

从公开材料看，TMOG 的核心动作不再是“提示词优化”，而是“需求工程化”。它把一份 107 页的文档作为 AI 编码的输入，让模型在同一套约束体系下完成代码生成、测试和检查。

这里的信息增量很明显：过去我们说“AI 编码”，更多是人先写几句描述，AI 返回一串代码，然后人再去改。严格说，这只是在用一个“自动补全增强版”，和真正意义上的工程化协作还差很远。

TMOG 要解决的，正是这个差距：让 AI 在动手写代码之前，先读到足够规格化的需求文档。这和传统软件工程里的 PRD 评审、详细设计评审在本质上没有区别，只是评审对象从人类工程师换成了大模型。

所以，与其把 TMOG 理解为一个“AI 编码器”，不如把它理解为一套“AI 编码需求描述规范”的实践框架。这一点，才是这则新闻对普通开发者真正有价值的部分。

2. 107 页文档到底解决了什么问题

2.1 AI 编码真正的瓶颈不是模型，而是输入

不少开发者已经体验过这类场景：你让 AI“写一个登录模块”，它确实生成了登录页、验证码、Token 刷新，看起来完整，但仔细一看，前后端接口字段对不上，错误码枚举缺少约定，数据库唯一索引也没加。

问题出在哪？出在输入太模糊了。AI 只能基于它见过的海量项目做合理猜测，而“合理猜测”恰恰是生产项目最不可控的因素。

107 页文档的作用，就是把这种模糊空间压缩到最小。它让模型不是在“猜”要做什么，而是在“查”文档里写了什么。就像你带一个聪明但缺乏项目经验的实习生，你给他讲得越细，他犯错的概率越低。

从任务管理器之父的视角看，这更像是在写内核模块规格说明书，每一个函数、每一条约束、每一处错误处理路径，都必须事先说清楚。

2.2 107 页文档的基本构成

虽然我们无法拿到 TMOG 文档全文，但按软件需求工程的通用框架，可以合理推断其构成。一份能驱动 AI 编码的规格文档，通常包含以下内容板块：

这 8 个板块组合起来，就是一份可以交付给 AI 的“需求规格说明书”。它之所以需要 107 页，不是因为文字啰嗦，而是因为真实软件系统的需求颗粒度本来就细。

2.3 传统提示词与工程化 Spec 的差别

很多人会问：我直接把需求文档丢给 AI，和 TMOG 这套做法有什么区别？

区别在于结构化和收敛性。

这里真正容易踩坑的地方是：很多人以为写需求文档是浪费时间，直接“告诉 AI 写一个模块”就行。但 AI 生成的代码一旦进入生产，问题排查成本远比写文档高得多。TMOG 的思路，本质上是把编码前推了几步，用更慢的前期换取更快的后期。

3. 给 AI 写的“产品需求文档”应该怎么设计

3.1 为什么 AI 需要 PRD

把 AI 编码需求描述规范理解成“给 AI 的一份 PRD”，是最容易上手的角度。

普通程序员每天打开需求文档，面对的是业务方的口头描述。给 AI 写需求，其实也是同一个道理。区别在于，业务方能容忍你追问细节，而 AI 不会主动追问——如果你不写清楚，它就按“训练时见过的最常见写法”来做。

所以，给 AI 写 PRD，比给人写 PRD 更强调完整性。你不需要写很多花哨的格式，但必须把“功能边界”和“验收条件”写死。

3.2 核心字段最少要包含什么

一个最小可用的 AI 编码需求描述规范，至少应包含以下字段：

• 项目定位：一句话说清这个东西给谁用，解决什么问题。
• 技术栈约束：语言、框架、依赖版本、运行平台，越具体越好。
• 功能清单：按模块拆分，避免一次性描述整个系统。
• 数据格式：字段名、类型、默认值、必填项。
• 异常与边界：输入超出范围怎么办，依赖服务失败怎么办。
• 可验证标准：最好像写测试用例一样写验收条件。
• 明确不做的事：防止 AI 擅自扩展范围。

3.3 一个最小需求文档模板

简单模板如下，可以直接复制保存为spec.md，后续喂给 AI 使用。

# Todo 命令行工具需求说明 ## 项目定位 一个命令行待办事项管理工具，用户通过终端创建、查看、完成和删除待办事项。 ## 技术栈约束 - 语言：Python 3.10+ - 框架：Click - 数据库：SQLite 3（标准库 sqlite3） - 平台：Windows 11 / Linux / macOS ## 功能需求 1. 添加待办：todo add "购买咖啡" -p high 2. 查看列表：todo list 3. 完成待办：todo done 1 4. 删除待办：todo remove 1 ## 数据模型 表名：todos 字段： - id INTEGER PRIMARY KEY AUTOINCREMENT - content TEXT NOT NULL - priority TEXT DEFAULT 'normal' - status TEXT DEFAULT 'pending' - created_at TEXT DEFAULT CURRENT_TIMESTAMP ## 验收标准 1. 所有命令必须在终端输出明确结果 2. 支持中文内容输入 3. 数据保存到 SQLite 文件，程序重启后不丢失 4. 非法参数必须输出 usage 信息，不能崩溃 ## 不实现范围 - 不做 Web UI - 不做用户登录 - 不做云端同步

这份模板虽然短，但已经具备 107 页文档的骨架：定位、技术栈、功能、数据结构、验收标准、边界范围。

4. Win11 上搭建 AI 编码环境

4.1 系统版本与开发环境

TMOG 与 Win11 绑定，但这不是说只有 Win11 能跑 AI 编码。更多时候，Win11 是实际开发机的运行环境，所以先把系统基础准备好。

根据不同版本 Windows 11 的实际情况，建议优先使用稳定版系统更新，避免在预览版或激进更新通道里折腾开发环境。系统重装、镜像下载、TPM 2.0 要求是 Win11 用户绕不开的话题，这里提一个容易被忽略的点：如果是在虚拟机里安装 Win11，经常遇到引导失败或 TPM 校验失败的问题，建议先在 BIOS 里启用虚拟化相关功能，使用最新版虚拟机软件，并确认镜像文件校验值正确。

另外，Win11 对中文用户最常见的两个干扰是右键菜单折叠和自动更新。不习惯新右键菜单的话，可以通过修改注册表或使用系统设置恢复经典的“显示更多选项”，但这属于个人习惯范畴；自动更新不建议直接永久关闭，开发环境更推荐设置“活动时间”，避免工作期间重启。

4.2 Python、Git 与基础工具链

大多数 AI 编码脚本依赖 Python。Win11 上配置 Python 的常见问题是环境变量没有生效。安装时建议勾选“Add Python to PATH”，安装完成后用下面的命令验证：

python --version py --version

如果你在 Win11 上同时装了多个 Python 版本，推荐用py启动器来区分。比如：

py -3.12 --version

Git 也是必装工具，AI 生成代码后，你需要在几分钟内完成实验、回滚和分支管理。建议把需求文档也纳入 Git 仓库，每次修改都能留下记录。

4.3 IDE 与 AI 编码插件

Win11 下主流的做法是使用 VS Code 或 JetBrains 系 IDE，再接入支持的 AI 编程插件。无论是使用国际主流 AI 编码工具还是国产 AI 编码工具，都要注意一点：不要让 AI 直接写入核心权限边界代码。

在 IDE 中选择模型时，建议根据项目类型选择性价比合理的模型。普通业务代码、脚本、测试代码可以用中小模型搞定；架构设计、复杂算法、底层并发代码，才需要把更完整的 Spec 上下文喂给更强的模型。

5. 完整示例：需求文档驱动的 AI 编码流程

5.1 项目结构设计

我们用一个最小项目跑通整个流程。先创建目录：

ai-todo/ ├── spec.md ├── load_spec.py ├── ai_client.py ├── generate_project.py └── generated/

5.2 读取 Spec 的脚本

先写一个读取需求文档的工具脚本，用于把 107 页文档或最小 Spec 载入内存。文件路径假设为load_spec.py。

# 文件：load_spec.py from pathlib import Path SPEC_PATH = Path(__file__).parent / "spec.md" CHUNK_THRESHOLD = 300000 # 字符数，按模型实际上下文调整 def load_spec(path: Path = SPEC_PATH) -> str: if not path.exists(): raise FileNotFoundError(f"需求文档不存在: {path}") content = path.read_text(encoding="utf-8") if len(content) > CHUNK_THRESHOLD: print("警告：文档过长，建议按模块拆分后再喂给模型。") return content if __name__ == "__main__": spec = load_spec() print(f"已加载需求文档，长度: {len(spec)} 字符") print(spec[:300])

长文档被一次塞进上下文，是 AI 编码最常见的失败原因。文档超过模型上下文窗口时，要做切块处理。这里不展开细节，但你在实际项目中一定会遇到。

5.3 构造 AI 请求的通用客户端

为了不让示例绑定某一个具体厂商 SDK，这里使用一个通用 HTTP 客户端。实际使用时，请按你选择的模型或服务商调整AI_API_URL、鉴权方式和解析逻辑。

# 文件：ai_client.py import os import requests def ask_ai(system_context: str, user_prompt: str) -> str: api_url = os.getenv("AI_API_URL", "https://your-ai-api.example/v1/chat/completions") api_key = os.getenv("AI_API_KEY", "") headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json", } payload = { "model": os.getenv("AI_MODEL", "your-model-name"), "temperature": 0.2, "messages": [ {"role": "system", "content": system_context}, {"role": "user", "content": user_prompt}, ], } try: resp = requests.post(api_url, headers=headers, json=payload, timeout=120) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] except requests.exceptions.Timeout: return "错误：AI 请求超时，请检查网络或减小 Prompt 长度。" except Exception as exc: return f"错误：{exc}"

如果你的模型服务商提供了官方 SDK，也可以替换成官方写法。上面的代码是“通用模板”，重点在于把 Prompt 结构固定下来。

5.4 把 Spec 和生成目标组合起来

下一步是读取 Spec，并把它与生成指令组合，交给 AI。这里没有把整个 Spec 一次性塞入，而是演示一个模块化改造思路。

# 文件：generate_project.py from load_spec import load_spec from ai_client import ask_ai SYSTEM_CONTEXT = """你是一名资深软件工程师。请严格按照用户提供的需求文档生成代码。 不要添加文档中未定义的功能，不要省略错误处理。 如果需求文档中有不明确之处，在代码注释中标记 TODO，不要自行假设。""" def build_prompt(spec: str, module_name: str) -> str: return f""" 请根据以下需求文档生成 {module_name} 部分的代码： 目标模块：{module_name} 输出要求： 1. 生成 Python 文件，包含完整可运行代码 2. 生成依赖清单 requirements.txt 3. 生成基础测试用例 test_{module_name}.py 4. 所有代码放在 generated/ 目录下 需求文档内容如下： {spec} """ if __name__ == "__main__": spec = load_spec() # 实际项目建议按功能模块循环调用，而不是一次生成整个系统。 # 这里以单个模块为例。 module_name = "todo_cli" prompt = build_prompt(spec, module_name) result = ask_ai(SYSTEM_CONTEXT, prompt) print(result)

这个脚本执行后，AI 返回的是带代码块的 Markdown 文本。实际使用中，你可以用正则把代码块提取出来，写入generated/目录。这里不再扩展解析部分，避免脱离主题。

6. 运行与验证：如何确认 AI 写的代码真的可用

6.1 最小运行验证

把 AI 返回的代码保存到generated/后，先做一个最简单的运行验证。

cd generated python -m venv .venv source .venv/Scripts/activate pip install click python todo_cli.py --help

Win11 下如果使用 PowerShell，激活命令是：

.\.venv\Scripts\Activate.ps1

如果这一步报“无法加载 ps1 文件”，通常是 PowerShell 执行策略限制，可以在管理员终端中查看执行策略，不需要打乱系统安全基线，用当前用户临时放开即可：

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

6.2 功能验证与自动化测试

小型项目可以用手工命令验证。以 Todo 工具为例，依次执行：

todo add "写周报" -p high todo list todo done 1 todo remove 1

每个命令的返回结果都要和 Spec 中的“验收标准”对照。

如果项目规模大一些，建议直接要求 AI 生成测试用例，并运行：

pip install pytest pytest test_todo_cli.py -v

这里要提醒一句：AI 生成的测试用例往往和 AI 生成的代码“互相自我验证”，存在盲区。你需要至少补 3 条手工测试用例，覆盖 Spec 中的边界条件。

6.3 失败时的第一排查顺序

如果 AI 生成的代码无法运行，按以下顺序排查：

1. 看是不是依赖版本问题：检查requirements.txt中的版本约束，是否存在不兼容。
2. 看是不是路径问题：确认是否使用了相对路径，工作目录是否与预期一致。
3. 看是不是 Spec 缺陷：回头检查需求文档是否遗漏了关键数据结构。
4. 看是不是模型上下文限制：Spec 过长导致 AI 忽略了后半部分需求。

没有工具能保证一次生成正确代码。TMOG 的 107 页文档之所以存在，也是在承认这个前提下，努力把不确定性从“功能层面”下降到“局部实现层面”。

7. 常见问题与排查思路

8. 最佳实践与工程建议

8.1 需求文档纳入版本管理

把spec.md当成第一份代码提交到 Git。后续每次需求变更，先改文档，再让 AI 根据新文档生成增量代码。这能形成完整的追溯链：看到某段代码不符合预期时，可以回看它是由哪一版需求产生的。

8.2 按模块分轮生成，不要一键生成整个系统

107 页文档虽然完整，但没有人会把 107 页一次性塞给 AI 然后等它输出整个项目。正确做法是：

• 第一轮：让 AI 输出项目结构和接口定义。
• 第二轮：让 AI 实现单个模块。
• 第三轮：让 AI 生成配套测试。
• 第四轮：人工代码审查，把问题反馈回 Spec。

每一轮的信息都是上一轮的输出，相当于把大任务分解成模型能稳定处理的小步骤。

8.3 对 AI 输出保持“最小信任”

AI 生成的代码，尤其是涉及文件操作、网络请求、数据库写入的部分，必须人工检查权限边界。不要让 AI 直接写出拥有最高权限的执行脚本。对于生产环境的变更，坚持最小权限、先测试、可回滚。

8.4 建立需求文档自动检查清单

一个简单但有效的做法：在 Spec 文件开头放置一段“开发者约束”，让 AI 先复述规则再生成代码。

## 开发者约束 - 所有文件操作必须显式关闭文件句柄 - 所有网络请求必须设置超时时间 - 所有数据库写入必须使用参数化 SQL - 所有函数必须有类型注解 - 不接受未经检查的异常处理

把这段约束放在每次喂给 AI 的 Prompt 开头，能显著减少低级别代码错误。

9. 总结与后续学习方向

TMOG 和它的 107 页文档，最有价值的不是那串数字，而是重新提醒了开发者：AI 编码不是“让人更懒”，而是“让人把需求想得更清楚”。

从这次事件里，至少可以提炼出三个能直接使用的结论：

第一，AI 编码需求描述规范应该前置。先写清楚数据模型、接口定义、验收标准，再开始和 AI 协作，返回的代码质量会明显更稳定。

第二，长文档不是用来一次性塞进上下文的，而是用来做模块拆分和检索的。107 页文档意味着工程化，工程化就意味着分治。

第三，Win11 环境下的 AI 编码工具链已经足够成熟，难点不在安装配置，而在于你怎么把自己的项目问题翻译成 AI 能执行的规格说明。

下一步，建议你从本文的 Todo CLI 最小示例开始，在自己的 Win11 开发机上跑通一遍“写 Spec → 读 Spec → 请求模型 → 本地验证”的流程。跑通之后，可以把同样的方法应用到真实项目模块里，再逐步加入测试自动化、代码审查和需求变更管理。

到时候你再回头看，就会发现 TMOG 是不是叫这个名字已经不重要了。重要的是，你已经把“让 AI 编码”从一句口号，变成了一套自己掌握的工作流。