最近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 用户按CtrlShiftEsc打开的窗口依然是这个系统的后代。他在微软工作多年也在 Windows 图形架构、DirectX 驱动模型等领域有大量底层经验。后来他离开微软运营了个人频道 Daves 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 编码的规格文档通常包含以下内容板块文档板块核心作用典型内容项目概述让 AI 建立全局认知项目背景、目标用户、系统边界功能需求定义“要做什么”用户故事、功能列表、优先级非功能需求定义“做得多好”性能指标、可维护性、合规要求数据模型定义“数据长什么样”实体关系、字段定义、索引约束接口设计定义“系统如何交互”REST/CLI 接口、参数、返回值错误处理定义“出错怎么办”错误码、日志格式、降级策略验收标准定义“怎样算完成”测试用例、检查项、边界场景拒绝项明确“不做什么”明确不实现范围防止幻觉扩散这 8 个板块组合起来就是一份可以交付给 AI 的“需求规格说明书”。它之所以需要 107 页不是因为文字啰嗦而是因为真实软件系统的需求颗粒度本来就细。2.3 传统提示词与工程化 Spec 的差别很多人会问我直接把需求文档丢给 AI和 TMOG 这套做法有什么区别区别在于结构化和收敛性。对比维度传统提示词工程化 Spec输入形式几段自然语言结构化的分章节文档需求颗粒度模糊依赖模型联想精确覆盖边界情况验收标准通常缺失严格定义可自动检查变更管理改提示词重新生成改文档走版本控制可追溯性低高每个功能都有依据幻觉容忍度高模型容易自由发挥低文档约束模型行为这里真正容易踩坑的地方是很多人以为写需求文档是浪费时间直接“告诉 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 --versionGit 也是必装工具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(encodingutf-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: fBearer {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, headersheaders, jsonpayload, timeout120) 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 --helpWin11 下如果使用 PowerShell激活命令是.\.venv\Scripts\Activate.ps1如果这一步报“无法加载 ps1 文件”通常是 PowerShell 执行策略限制可以在管理员终端中查看执行策略不需要打乱系统安全基线用当前用户临时放开即可Set-ExecutionPolicy -Scope CurrentUser RemoteSigned6.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 生成的代码无法运行按以下顺序排查看是不是依赖版本问题检查requirements.txt中的版本约束是否存在不兼容。看是不是路径问题确认是否使用了相对路径工作目录是否与预期一致。看是不是 Spec 缺陷回头检查需求文档是否遗漏了关键数据结构。看是不是模型上下文限制Spec 过长导致 AI 忽略了后半部分需求。没有工具能保证一次生成正确代码。TMOG 的 107 页文档之所以存在也是在承认这个前提下努力把不确定性从“功能层面”下降到“局部实现层面”。7. 常见问题与排查思路问题现象可能原因排查方式解决方案Win11 执行 Python 命令报“不是内部或外部命令”Python 未加入 PATH在终端执行py --version验证安装时勾选 Add Python to PATH或手动配置环境变量AI 生成代码后本地无法安装依赖包名或版本是 AI 编造的查看 pip 报错信息去官方仓库确认让 AI 先生成 requirements.txt再人工审核版本号超过模型上下文窗口Spec 文档过长查看请求报错或日志中的 token 消耗按模块拆分或使用 RAG 方式只检索相关片段生成的 API 调用和实际 SDK 不符模型训练数据存在过时信息对比 SDK 官方文档在 Spec 中写入官方文档链接和关键方法签名Win11 中 Docker 引擎无法启动虚拟化功能未开启或版本兼容问题检查 Hyper-V/WSL2 状态按微软官方要求开启相关 Windows 功能Ch340 驱动在 Win11 上安装失败驱动未签名或系统版本过新查看设备管理器错误码从芯片厂商官网下载对应 Win11 版本驱动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 编码”从一句口号变成了一套自己掌握的工作流。
