给产品经理和 AI 实作者的实战方法论，2026-05-22 版

产品经理不必先成为工程师，也可以开始用 AI 生产软件。

过去这段时间，从静态页面、插件、公众号 HTML，到一个技术复杂度很高的平台型产品，我越来越确认一件事：AI Coding 不是“让不会技术的人假装会写代码”，而是让懂业务、懂用户、懂取舍的人，第一次可以直接参与软件生产。

来自詹老师的 AI Coding 实战笔记｜添加本人微信：13136092523

先看证据看研发流水线

PART 1

为什么这套经验值得听

这不是“我觉得 AI 很厉害”的空泛判断，而是接近一年独立 AI Coding 之后，尤其最近一周高强度实战里沉淀出来的经验。数据不能证明每个判断都绝对正确，但能说明一件事：这些原则来自真实生产，不是旁观者评论。

近一周仓库提交 6 次 Git commit，以一个 AI 智能体平台项目为例，集中在平台运行、执行内核接入、监控与稳定性。

涉及文件 154 个文件被提交变更，覆盖前端、API、worker、协议、文档和部署。

代码变更量 4.9万+ 新增行数约 49,006 行，删除 240 行；包含依赖锁文件和工程骨架。

AI 协作消耗 5.45亿 项目相关 Codex 会话 token 粗筛量级，不等同于账单金额。

最近一周的两条曲线

代码提交告诉你“产出了多少工程痕迹”，token 消耗告诉你“AI 参与了多少思考和试错”。两个数字放在一起看，才接近 AI Coding 的真实样子。

5/21

45,279 行

5/22

3,967 行

5/21

2.02亿 token

5/22

0.73亿 token

统计口径：Git 数据来自当前仓库 2026-05-15 至 2026-05-22 的提交记录； token 数据来自本机 Codex 会话日志，按“AI 智能体平台项目名 / 前端 / API / worker / 执行内核”等关键词粗筛并按会话最大累计值归并。它适合作为“实战强度”的证据，不适合作为精确成本核算。

对没有工程基础的人来说，这些数字的意义不是炫耀“写了很多代码”，而是说明：产品经理已经可以通过 AI 进入真实软件生产线。但越能生产，越需要懂流程、懂概念、懂验收。

阅读口径

全文以“AI 智能体平台”为例

如果你第一次接触这类项目，可以先把它理解成一个能创建智能体、安装工具、调用模型、执行任务、展示结果的平台。文章里出现的前端、API、worker、部署、监控，都会围绕这个例子来讲。

署名

来自詹老师的实战经验

这份课程来自詹老师近一年独立 AI Coding 的实战笔记。交流 AI Coding、AI 产品经理转型和企业智能体落地，可添加本人微信：13136092523。

PART 2

我的 AI Coding 实践宗旨

这不是一份“你会不会写代码”的评分表，而是一份从真实协作里长出来的方法论。如果一个产品经理过去能写 PRD、做原型、盯上线，那么在大模型时代，完全可以把手伸进软件生产现场。但前提是：要尊重工程，不迷信 AI，也不把自己的不懂包装成战略。

一句话宗旨

AI Coding 的核心，不是产品经理亲手写出每一行代码，而是用产品判断组织 AI 的工程产能：把目标说清、把边界框住、把风险摊开、把结果验实，然后让代码真正服务业务。

实战来源

从轻量内容到复杂平台

过去这段时间的任务跨度很大：最简单的是静态页面和公众号 HTML，往前一步是插件、Skill 和自动化工具，最复杂的是平台型产品。复杂度不同，协作方法也必须不同。不能用做海报的节奏做平台，也不必用平台级流程拖慢一个当天就该上线的页面。

原则 1

先定义产品结果，再谈代码实现

AI 很擅长执行，但它不天然知道什么叫“有用”。产品经理要先讲清用户、场景、动作、成功结果和不可接受的失败。代码只是这些判断的落地形式。

原则 2

复杂度决定协作方式

静态页可以快，公众号 HTML 可以美，插件要可复用，平台产品必须讲架构、权限、数据、部署、监控和回滚。任务越复杂，越不能只追求“先跑起来”。

原则 3

产品经理的优势不是语法，是判断

你不一定会写 TypeScript、部署 Nginx 或设计数据库，但你能判断用户是否需要、路径是否顺、成本是否值得、风险是否可接受。这些判断是 AI 替代不了的。

原则 4

承认不懂，比假装懂更高级

不懂 worker、Git、仓库、部署很正常。危险的不是不懂，而是不问、不验、不要求 AI 解释。好的 AI 协作，应该允许产品经理把工程黑箱一点点拆开。

原则 5

所有 AI 产出都要回到证据

AI 说“完成了”没有意义。真正的完成是：能打开、能操作、能复现、测试通过、部署可访问、失败路径能解释。没有证据，就只是一次漂亮的聊天。

原则 6

越是大产品，越要把 AI 关进流程

平台型产品不是靠一次灵感写出来的。AI 必须在需求、分支、测试、文档、部署和监控这些流程里工作，否则越写越快，失控也越快。

四种任务打法

不同任务，不同节奏

写公众号和做静态页，重点是表达、排版、视觉和快速发布；做插件和 Skill，重点是把一次经验沉淀成可复用能力；做平台产品，重点是架构边界、数据流、权限、稳定性和长期维护。

对所有产品经理

别等“学会编程”再开始

最好的入门方式不是先啃完一门语言，而是从一个真实小任务开始：做一个页面、改一个表单、生成一篇可发布 HTML、封装一个小工具。每次做完都复盘：我说清了什么，AI 猜错了什么，我验收了什么。

OK 1

OK，从一个小作品开始

不要一上来就做平台。先做一个能发布的页面、一篇能转发的公众号 HTML、一个能重复使用的小工具。小作品会逼你经历完整闭环：需求、生成、修改、预览、发布、反馈。

OK 2

OK，让 AI 写代码，但你必须管验收

你可以不懂每一行代码，但必须知道用户路径是否走通、页面是否能打开、输入错误时有没有提示、上线后有没有地址和证据。AI 负责生产，你负责验真。

OK 3

OK，把内容工作也工程化

公众号、报告、海报、课程页不只是“写文案”。它们可以变成 HTML、模板、组件、Canvas 图片和一键复制工具。这会让内容生产从手工排版变成产品化流程。

OK 4

OK，把重复经验封装成插件

如果一个任务你做了三次，就应该考虑封装成 Skill、插件、脚本或流程模板。 AI Coding 的价值不只是完成一次任务，而是把方法沉淀下来，下次更快、更稳。

OK 5

OK，挑战复杂平台，但必须拆阶段

平台型产品可以用 AI 推动，但不能一口吞。先做 POC，再做 P0 闭环，再补权限、数据、监控、部署和安全。每一阶段都要有可验证产物。

OK 6

OK，不懂技术，但不要放弃追问

你可以直接问：这个文件负责什么？为什么需要 worker？这次改动怎么回滚？哪个风险还没验证？追问不是显得外行，而是在建立自己的工程判断力。

我的真正判断是：AI Coding 会让更多非工程背景的人进入创造现场，但进入现场不等于可以无视工程。产品经理未来最值钱的能力，是把业务判断、工程常识和 AI 执行力组织成一个稳定闭环。

实战加餐

从零开始的四个实战动作

如果你没有技术背景，不要一上来背概念，也不要急着做大平台。最稳的路径，是先用一个真实小项目走完整闭环：把想法说清楚，让 AI 生成第一版，自己验收结果，再把重复经验沉淀成模板、插件或 Skill。

动作一：先打掉两个误解

误解一：不会代码就不能做 AI Coding。误解二：AI 能写代码，所以不需要工程流程。

你不需要先变成工程师，但必须开始理解软件怎么生产。
你可以让 AI 写代码，但不能把判断权完全交给 AI。
信心来自小闭环，不来自一句“AI 很强”。

动作二：看懂软件怎么被生产出来

用餐厅、装修、工厂流水线三个类比，解释需求、前端、后端、API、worker、Git、部署。

你要能听懂“一个点击如何走完整个系统”。
你要知道每个概念出现在研发流水线哪一站。
重点不是记名词，而是知道该问谁、问什么。

动作三：拆真实项目，而不是背抽象概念

把静态页面、公众号 HTML、插件/Skill、AI 智能体平台放到同一张项目地图里对比。

为什么静态页可以快，平台产品必须慢半拍。
为什么公众号 HTML 也可以工程化。
为什么复杂平台要拆 POC、P0、上线和监控。

动作四：做一个自己的小闭环

选一个真实小任务，用模板向 AI 下需求，再用验收清单检查输出。

可选任务：课程页、公众号 HTML、小工具、插件说明、产品原型。
必须写出目标、边界、验收标准和风险问题。
最后用“证据”汇报，而不是说“AI 做完了”。

你要带走什么

三件真正有用的东西

一份自己的 AI Coding 任务描述模板，一张研发流水线图，一份上线前验收清单。对零技术背景的人来说，最重要的不是马上懂多少代码，而是下一次遇到真实任务时，知道怎么把 AI 带进工作现场。

学习方法

先用故事，再落概念

不要从“API 的定义”开始背。先想一个用户点按钮、前端发请求、后端登记、worker 在后台执行、页面显示结果的故事。故事通了，再把 API、数据库、worker、日志这些词贴上去。概念必须长在案例里，才不会变成死记硬背。

练习 1

把一个想法变成 AI 可执行需求

写下一个“我想做一个工具”的原始想法，再改写成：用户是谁、要完成什么动作、成功结果是什么、不做什么、验收标准是什么。这个练习能立刻暴露需求是否清楚。

练习 2

用验收清单检查 AI 输出

拿一个 AI 生成的页面或方案来检查：能不能打开、有没有移动端问题、有没有空状态、错误提示是否清楚、是否有发布地址。训练的不是技术细节，而是验真意识。

练习 3

把重复经验封装成 Skill

选一个自己每周都做的工作，比如写周报、做审批分析、生成公众号、整理访谈纪要。先写出输入、步骤、输出和质量标准，再理解为什么 Skill 是“经验产品化”。

工具选择

先选一个能真正干活的 AI Coding 工作台

很多人卡在临门一脚，不是因为不会编程，而是不知道到底该用什么工具开始。我的建议很简单：不要把时间浪费在十几个工具横评上。先选一个能读项目、改文件、跑验证、看结果的工作台，把一个真实小项目跑通。

海外环境

优先用 Codex

如果账号、网络和工作环境都允许，Codex 是最值得优先使用的 AI Coding 工作台。它适合做真实项目：读代码、改文件、跑命令、看错误、验证页面、整理变更证据。对复杂平台、长任务、多文件改动和上线前检查，Codex 的价值会更明显。

国内环境

先用 Qoder 跑起来

如果你在国内环境里做 AI Coding，Qoder 更适合作为起步工具。先别追求一步到位，先让它帮你完成静态页、课程页、插件说明、小工具、项目拆解和基础代码修改。目标不是炫工具，而是把第一次完整闭环跑通。

有条件进阶

Codex 或 Claude Code

如果你有更好的账号、网络、预算和工程环境，尽量用 Codex；如果你已经愿意接触终端、能接受命令行里的协作方式，也可以考虑 Claude Code。其他工具先不用作为主线，避免入门期被工具选择消耗掉。

判断标准

一个 AI Coding 工具至少要能做五件事

第一，能读懂当前项目结构；第二，能直接修改文件；第三，能运行命令、测试或预览；第四，能根据报错继续修；第五，能告诉你改了什么、验证了什么、还有什么风险。如果一个工具只能聊天，不能进入项目现场，它更像顾问，不像工作台。

第一天怎么用

不要从大平台开始，从小闭环开始

第一天最适合做三个小任务：生成一个静态页面，修改一个现有页面，发布一个可访问地址。这三个任务会让你同时碰到需求描述、文件修改、本地预览、移动端检查和部署验证。一旦这条线跑通，你再去碰插件、Skill 和平台项目。

轻任务

静态页、公众号 HTML、课程页

这类任务重点是表达、排版、预览和发布。你要要求 AI 给出本地预览地址、移动端检查结果、线上访问地址，以及哪些地方还没验证。

中任务

插件、Skill、小工具

这类任务重点是复用。你要让 AI 说清楚输入是什么、处理步骤是什么、输出是什么、失败时怎么提示，以及下一次怎么直接复用。

重任务

AI 智能体平台

平台项目必须拆阶段。先做 POC，再做 P0 闭环，再补权限、数据、监控、部署和安全。工具再强，也不能用“一口气做完整个平台”的方式推进。

工具选择的底层逻辑是：少换工具，多跑闭环。一个工具只要能稳定读项目、改文件、跑验证、给证据，就先用它把自己的 AI Coding 手感练出来。等你能稳定做出东西，再考虑更复杂的组合。

PART 3

先看传统软件研发流水线

软件不是从“写代码”开始，也不是写完代码就结束。传统研发流水线本质上是一条把不确定想法变成稳定线上产品的生产线。 AI Coding 没有推翻这条线，它只是把其中很多环节提速了。越是复杂产品，越要先看清这条线。

机会与问题

先确认为什么要做：用户是谁，痛点是什么，业务上值不值得投入。

产品经理主导：决定做不做。

需求定义

把模糊想法写成可执行需求：目标、范围、用户故事、成功标准、暂不做什么。

AI 可辅助：整理 PRD、拆用户故事。

原型与验收

画出页面和流程，提前定义正常路径、异常提示、空状态和验收标准。

关键动作：先说清“怎么算完成”。

技术方案

决定前端、后端、数据库、worker、第三方服务、部署方式和核心风险。

产品经理要问：哪些是事实，哪些是假设。

任务拆解

把大目标拆成小任务：页面、接口、数据表、后台任务、测试、文档、部署。

AI 最适合：把大需求拆成可执行清单。

开发准备

准备仓库、分支、依赖、环境变量、测试数据和本地启动方式。

这里会出现：repo、branch、env。

编码实现

写前端页面、后端 API、worker 执行逻辑、数据库读写和适配层。

AI 很强，但必须被边界和验收牵引。

本地联调

确认页面能打开、接口能通、数据能保存、worker 能跑、错误能暴露。

一句话：不要把没跑通的东西叫完成。

测试与审查

用自动测试、手动验收、代码审查确认没有明显回归和安全风险。

这里会出现：test、review、PR。

构建与部署

把本地代码打包，发布到测试环境或生产环境，让用户能通过地址访问。

这里会出现：build、deploy、domain。

监控与告警

上线后观察错误率、响应时间、任务失败、成本、日志和用户反馈。

上线不是终点，是开始暴露真实问题。

复盘与迭代

基于数据和反馈决定继续优化、砍掉、重构、扩展，进入下一轮循环。

产品经理主导：判断下一步价值。

高层先做什么

先把“为什么做”和“做到哪”讲清楚

不要从“帮我写个接口”开始，而是从问题、用户、场景、目标和验收开始。 AI 越强，越需要一个清楚的上游输入，否则它只是更快地跑偏。

AI 插在哪里

AI 不是替代流水线，而是加速每一站

AI 可以帮你写 PRD、画页面、拆任务、写代码、补测试、查日志、写文档。但需求取舍、风险接受、上线节奏和最终验收，仍然要有人负责。

复杂度判断

越复杂，越要慢半拍设计流程

静态页可以快速发布，插件要考虑复用，平台产品必须把权限、数据、worker、监控和回滚纳入设计。不是所有任务都配同一套流程。

这就是后面所有概念的牵引线：Git 管的是开发准备到审查，API 管的是前后端协作，worker 管的是后台执行，测试和部署管的是上线可信度，监控管的是上线后的真实世界。

案例 1：课程页

一个静态页面也要走小流水线

比如这套 AI Coding 课程页，看起来只是一个 HTML 文件，但它仍然经历了需求定位、内容结构、视觉样式、本地预览、移动端检查和 Cloudflare Pages 发布。它没有复杂后端，所以流水线短，但不是没有流水线。

案例 2：公众号 HTML

内容产品也可以工程化

公众号文章不是写完文字就结束。真正能发布的公众号 HTML 要考虑一键复制、移动端排版、头图和金句图转 PNG、复制到公众号后台是否散版。这就是“内容工作工程化”的典型案例。

案例 3：插件 / Skill

重复工作要变成能力包

当一个任务被反复执行，比如写公众号、做流程图、生成课程、整理审批材料，就不应该每次重新描述。把它做成 Skill，等于把经验封装成一个可复用的工具包。

案例 4：AI 智能体平台

复杂平台必须拆阶段

AI 智能体平台不是一个页面，而是一组系统：前端、API、worker、协议、适配层、数据库、监控、部署。所以它要先做 POC 证明关键假设，再做 P0 闭环，最后再补权限、安全和规模化。

案例 5：Cloudflare 发布

上线不是一句“发布一下”

把课程页发布到 pm-ai-coding-course.pages.dev，本质是把本地文件交给云端入口。产品经理要关心的是：地址是否可访问、是否沿用原路径、刷新后是否是新版本、移动端是否正常。

案例 6：排错和复盘

出问题时，先找证据

比如头图太乱、公众号复制散版、页面没有沿原路径发布，这些都不是抽象问题。正确做法是回到证据：截图、页面结构、复制结果、线上地址、发布时间，再决定怎么修。

PART 4

沿着流水线解释核心概念

技术概念不应该一个一个死记。先把它们放回研发流水线里：哪些出现在开发准备，哪些出现在编码实现，哪些服务于联调测试，哪些决定上线后的稳定性。下面尽量用白话讲，先听懂“它像什么”，再记住“它解决什么问题”。

1. 前端、后端、API、数据库是什么

这四个词可以先用餐厅来理解：前端像菜单和餐桌，后端像后厨，API 像服务员传单，数据库像仓库和账本。用户点菜时看不到后厨，但没有后厨和账本，餐厅就跑不起来。

前端

用户能看到和点击的界面。比如登录页、聊天框、按钮、表格。在 AI 智能体平台例子里，前端常见目录可能叫 apps/web。

后端

负责真正办事：判断能不能登录、有没有权限、数据存哪里、任务交给谁。在例子里，后端常见目录可能叫 apps/api。

API

前端和后端说话的固定通道。就像前台不能直接冲进后厨，只能按规则下单：登录、创建 Agent、发送消息、查状态。

数据库

长期保存东西的地方。账号、配置、任务、消息、运行记录都放这里。没有数据库，系统重启后就像餐厅账本丢了。

2. worker 到底是什么

worker 是“后台执行员”。前端发出任务，API 负责登记和分派，worker 在后台真正执行耗时动作：调用 AI 执行内核、跑任务、处理文件、更新状态、写日志。

举个例子：用户点“生成一个完整方案”，页面不应该卡住十分钟。API 先说“收到”，worker 在后台慢慢干活，干完再把结果和状态送回来。

为什么需要 worker

因为 AI 任务可能跑很久，不能让用户页面一直卡住等结果。像外卖平台不会让你站在厨房门口等。

worker 和 API 的区别

API 像前台接待，worker 像后台处理。API 要快，worker 可以慢慢干重活。

在智能体平台里的例子

apps/worker 可以接收平台任务，再通过适配层交给真正的 AI 执行内核去处理。

产品问题

你要问：任务排队吗？失败重试吗？用户能看到进度吗？中断后能恢复吗？

3. 协议、SDK、Adapter、Runtime 是什么

这组词听起来很技术，其实都和“不同系统怎么配合干活”有关。你可以把它们理解成：说话格式、工具包、翻译官和发动机。

协议

约定好的说话格式。比如快递单必须有收件人、地址、电话；平台任务也必须有类型、输入、状态、产物。

SDK

别人提供的工具包。就像买家具附带螺丝刀和说明书，让你更容易使用对方能力。

Adapter

翻译官。平台内部说一套话，外部 AI 执行内核说另一套话，Adapter 负责互相翻译。

Runtime

真正跑任务的发动机。页面和 API 都不是发动机，复杂 AI 执行通常要交给专门的 Runtime。

4. 本地、测试、生产、上线是什么

这四个词对应“东西在哪里跑”。本地像厨房试菜，测试环境像内部试吃，生产环境像正式开店，上线就是把菜端给真实客人。

本地

开发者电脑上的运行环境，适合快速试错。坏了只影响自己，不影响真实用户。

测试环境

给团队验证功能的环境。像彩排，尽量接近真实，但台下还不是正式观众。

生产环境

真实用户访问的环境。这里不能随便试错，要能监控、回滚、排查。

上线

把通过验证的代码发布到真实可访问地址。上线不是“发出去就完”，还要看日志和监控。

5. AI 产品里常见的 AI 概念

AI 产品不是只接一个聊天模型。真正做产品时，你会同时遇到模型、上下文、工具、Agent、知识库和评测。它们分别管“会不会答、看到了什么、能不能动手、能不能连续干活、懂不懂企业知识、稳不稳定”。

模型

负责理解和生成内容的大脑。像不同员工，有的写作强，有的代码强，有的便宜快，有的贵但稳。

上下文

AI 当前能看到的信息。就像你开会前给它的材料，没放进材料包的东西，它就可能不知道。

工具调用

AI 不只聊天，还能动手调用搜索、文件、浏览器、部署等工具。像员工不只出主意，还能打开系统办事。

Agent

能围绕目标连续工作的 AI。它会拆任务、调用工具、看结果、再继续，不是只回答一句话就结束。

RAG

先翻资料，再回答问题。比如问公司制度，AI 先去知识库找原文，再根据原文回答，减少胡编。

评测

给 AI 做考试。用一批固定题目和评分标准看它稳不稳。没有评测，就只能靠感觉说“好像还行”。

6. 日志、监控、告警为什么重要

AI 产品失败时，不一定是代码崩了。可能是模型慢、token 超限、第三方接口变了、用户输入太长、worker 队列堵了。日志负责回答“发生了什么”，监控负责回答“现在是否健康”，告警负责在坏事扩大前叫醒人。

产品经理要看：成功率、耗时、失败原因、用户等待时间、产物质量。
工程师要看：错误堆栈、请求 ID、服务状态、资源占用、重试次数。
AI 产品额外要看：模型调用成功率、成本、上下文长度、工具调用链路。

你可以一直用同一个故事理解这些概念：用户在页面点一次“生成方案”，前端负责让按钮可见， API 负责接单，数据库负责记账，worker 负责后台干活，AI 模型负责产出内容，日志负责留下证据，监控负责告诉你系统是否健康。所有概念都能放回这个故事。

点击按钮的故事

用户只看到一个按钮，系统背后是一条链

用户点“创建智能体”，前端收集表单，API 校验权限，数据库保存配置，worker 可能初始化任务，日志记录动作。只要先懂这条链，就不会把软件理解成“页面上多了一个按钮”。

失败路径的故事

真正的产品能力，常常藏在失败时

如果模型调用失败，用户看到什么？如果 worker 排队太久，页面怎么提示？如果数据库没保存成功，能不能重试？产品经理不需要先会修代码，但必须会追问这些失败路径。

成本的故事

AI 产品多了一个新账本：token 成本

传统软件主要看服务器和人力成本，AI 产品还要看模型调用成本。一个功能如果每次都把大量无关资料塞进上下文，可能能跑，但会慢、贵、难控。产品经理要学会把“效果”和“成本”一起验收。

PART 5

Git：你必须懂的版本管理

在研发流水线里，Git 主要管“开发准备、编码实现、测试审查、合并发布”这几站。它不只是程序员的工具，而是项目的“时光机”和“交接单”。你不用记命令，但要知道每个状态意味着什么。

工作区 AI 或人刚改完的文件。还没有正式记录。

暂存区 准备打包进下一次提交的文件清单。

提交一次带说明的版本快照，可以回看和回滚。

推送把本地提交同步到远端平台。

合并/发布 进入主分支或触发线上部署。

核心解释

暂存区是什么

暂存区就是“下一次提交的购物车”。工作区里可能改了十个文件，但你可以只把其中五个放进暂存区，然后提交成一个清晰主题，比如“修复登录错误提示”。

核心解释

分支是什么

分支就是并行工作线。主分支保持相对稳定，新功能在自己的分支上做，做完验证后再合并。这样 AI 试错不会直接污染主线。

核心解释

远端仓库是什么

远端仓库通常在 GitHub、GitLab、Gitee 这类平台上。它是团队共享代码和触发部署的地方。本地电脑坏了，远端还在。

核心解释

Pull Request 是什么

Pull Request 是“请求把我的分支合进主分支”。它通常包含改了什么、为什么改、测试结果、代码审查意见。对 AI Coding 来说，它是最好的质量闸口。

你以后可以这样要求 AI：先说明当前分支和改动范围，再改代码；改完后展示变更摘要、测试结果和是否需要提交。这句话能把很多混乱挡在门外。

实战例子

改课程页时，Git 像修订记录

你要求“只增加案例，不改样式”，AI 改完后应该能说清：改的是课程 HTML 的哪些段落，有没有动 CSS，是否影响导航和脚本。Git 的价值就是把这些变化留下证据。

实战例子

修公众号头图时，分支像安全试验台

头图太乱要改，但不能把整篇文章弄坏。正确做法是只改画头图的那一小段逻辑，再重新渲染检查。分支和提交让这种小步试错更可控。

实战例子

平台产品更需要清晰提交

如果一次提交同时改前端、API、worker、部署脚本和文档，产品经理就要问：这些改动是不是同一个目标？能不能拆成更清楚的提交？以后排查问题时，清晰提交会救命。

PART 6

示例：AI 智能体平台的项目地图

为了让没有工程基础的人也能听懂，下面用一个“AI 智能体平台”做例子。你可以把它理解成：用户能创建智能体、配置工具、发起任务，平台在后台调用 AI 执行内核并返回结果。每个目录都对应研发流水线里的某一类工作。

apps/web

用户界面。 登录、看仪表盘、创建 Agent、聊天、管理 Skill、看监控这些都在这里。

apps/api

产品中台。 前端所有请求先到这里，负责权限、业务逻辑、状态、数据读写和任务分发。

apps/worker

后台执行员。 处理耗时任务，把平台任务交给 AI 执行内核或其他自动化工具。

packages/platform-protocol

内部协议。 规定平台内部如何描述 Agent、任务、事件、产物和状态。

packages/runtime-adapter

执行内核转接器。 把平台内部协议翻译成某个 AI 执行内核能理解的调用方式，也做降级和错误处理。

docs

项目记忆。 记录架构决策、部署说明、执行内核验证口径和实施计划。

infra

上线机器配置。 包括 Nginx、systemd 等，让服务在服务器上稳定运行。

spikes/runtime-client

验证实验。 用最小成本证明某个外部 AI 执行能力能不能满足关键假设。

几个仓库怎么分

当前更适合单仓库，多应用

你现在做的是平台早期阶段，用一个仓库管理前端、API、worker、协议、适配层和部署文档更合适。这叫 monorepo，优点是协作快、改协议时前后端能一起改。

什么时候拆仓库

当团队和边界变大再拆

如果未来前端、后端、SDK、部署平台分别由不同团队负责，发布节奏也不同，再考虑拆成多个仓库。现在过早拆仓库，只会增加沟通成本。

平台案例 1

创建 Agent 是一条端到端链路

前端展示表单，API 校验字段和权限，数据库保存 Agent 配置，协议层规定配置长什么样。产品经理要验收的不只是“按钮能点”，还要看创建后能不能再次打开、编辑、删除和出错提示。

平台案例 2

执行一次任务要经过 worker

用户发起任务后，API 先登记任务，worker 在后台调用执行内核，状态从排队、运行、成功或失败不断变化。产品经理要问：用户能不能看到进度？失败后能不能重试？日志能不能追到原因？

平台案例 3

适配层是平台的防抖垫

外部 AI 执行内核可能升级、报错、返回格式变化。适配层把这些变化挡在平台内部协议之外。对产品经理来说，这意味着平台不能把所有能力直接绑死在某一个外部工具上。

理解平台项目，不要一开始盯着技术架构图。先看一个用户故事： “我创建一个智能体，让它执行一个任务，最后看到结果。”再把这个故事拆成前端、API、数据库、worker、协议和适配层。这样更容易知道每一层到底解决什么问题。

PART 7

产品经理的 AI Coding 协同流程

你未来跟 AI 协作，最重要的不是“说得很技术”，而是把研发流水线的上游输入讲清楚：目标、边界、验收和风险。下面这套流程可以反复用。

Step 1

先说业务目标

不要一上来要求“写接口”。先说用户是谁、要完成什么动作、成功后页面或数据应该怎样。

Step 2

限定范围

说明只改哪块，不碰哪块。比如只改登录弹窗，不重构整个认证系统。

Step 3

要求先读现状

让 AI 先看相关文件、接口、测试和文档，再下结论。工程里最怕凭感觉改。

Step 4

给验收标准

明确怎样才算完成：页面可见、接口返回正确、测试通过、错误情况有提示、部署地址可访问。

Step 5

要求解释风险

让 AI 说明可能影响哪些旧功能、有没有数据风险、有没有安全风险、有没有上线注意事项。

Step 6

最后要证据

完成后不要只听“好了”。要看改了哪些文件、验证了什么、哪里没验证、线上地址是什么。

少这样问

“你帮我把平台做完整。”

这个问题太大，AI 会自己脑补范围。最后很可能做出很多看似热闹、实际不可控的东西。

改成这样问

“先完成 P0 闭环。”

“用户能登录，创建一个 Agent，发起一次任务，worker 调用 AI 执行内核，前端看到状态和产物。不做计费、不做多租户高级权限，完成后给我验证路径和未完成风险。”

场景 1：做页面

把“好看一点”改成可验收语言

不要只说“页面高级一点”。可以说：首屏要让用户 5 秒内知道这是 AI Coding 课程；移动端不能横向滚动；按钮必须有明确去向；发布后给我可访问地址和截图。

场景 2：做公众号 HTML

把“格式别乱”拆成工程要求

可以要求：正文放在独立复制区；复杂视觉块转 PNG；不要依赖 flex/grid；图片宽度固定 660；复制后标题、段落、作者名片都能保留。这就是产品语言转工程语言。

场景 3：做平台功能

把“大功能”拆成 P0 闭环

比如“智能体任务执行”可以先拆成：创建任务、worker 接收、调用执行内核、更新状态、前端展示结果。先完成这条链，再谈高级权限、计费、团队协作和监控大屏。

协同 AI 的关键动作是“把模糊要求翻译成可验证要求”。你可以不懂代码，但必须学会把 “好看、稳定、完整、能用”翻译成页面、路径、数据、状态、错误、部署和证据。

PART 8

30 天补课路线

你的目标不是学会所有技术，而是建立能和 AI 工程师对齐的最低工程素养。按这四周学，够你把 AI Coding 提升一个大台阶。

第 1 周：工程地图

先背下研发流水线，再把前端、API、worker、数据库、部署、监控放进同一张图里。

每天用自己的话解释 3 个概念。
能说清一个用户请求如何从页面走到后端。
能看懂一个 AI 智能体平台样板目录的职责。

第 2 周：Git 和版本管理

理解工作区、暂存区、提交、分支、推送、PR、回滚。

每次让 AI 改动前先确认分支。
每次改动后要求变更摘要。
学习如何阅读一次提交记录。

第 3 周：AI 产品基础

理解模型、上下文、工具、Agent、RAG、评测、成本和安全。

给每个 AI 功能写输入、输出、失败路径。
为核心任务设计 10 条评测用例。
区分“演示效果”和“生产能力”。

第 4 周：上线闭环

学会要求本地验证、测试、预览、部署、监控、回滚说明。

每次上线前问 5 个风险问题。
每次上线后看访问地址和错误日志。
建立自己的产品验收清单。

实战项目 A

做一页自己的 AI 工作流主页

让 AI 帮你做一个静态页面，展示你的工作流、工具、案例和联系方式。这个项目小，但能完整经历：内容结构、页面生成、移动端检查、本地预览、线上发布。

实战项目 B

把一篇文章做成公众号 HTML

目标不是写文章，而是体验“内容工程化”：头图、金句图、信息框、作者名片、一键复制。这个项目会让你理解：代码不只服务软件，也服务内容生产。

实战项目 C

拆一个平台型产品的 P0 闭环

不要求立刻做完整平台。只要写清：第一个用户是谁，最短路径是什么，前端要什么， API 要什么，worker 做什么，怎么验收。这个练习能把产品经理带进真实工程思维。

PART 9

以后直接复制的提示词模板

你可以把下面这些当成“AI 工程协作话术”。越是技术小白，越要用固定模板保护自己。

需求实现模板

我想实现一个功能：
用户是谁：
用户要完成的动作：
成功后的界面或数据结果：
不要改动的范围：
验收标准：
1. 
2. 
3. 

请你先阅读相关代码和文档，告诉我你理解的现状、需要改哪些地方、有哪些风险。确认后直接实现，并在完成后给我变更摘要、验证结果和未验证风险。

排查问题模板

现在出现一个问题：
我看到的现象：
我期望的结果：
发生在哪个页面或流程：
最近改过什么：
是否影响真实用户：

请按“复现、定位、最小修复、验证、风险说明”的顺序处理。不要先大改，先找根因。

上线前检查模板

请帮我做上线前检查：
1. 当前分支是什么？
2. 这次改了哪些文件和功能？
3. 本地构建和测试是否通过？
4. 有没有环境变量、密钥、数据库迁移或部署配置变化？
5. 如果上线失败，怎么回滚？
6. 上线后我应该看哪个地址、哪些日志、哪些指标？

学习解释模板

请用产品经理能听懂的话解释这个技术概念：
概念名：
它解决什么问题：
在一个 AI 智能体平台例子里可能对应哪个文件或模块：
如果它坏了，用户会看到什么：
我作为产品负责人需要问哪 3 个问题：

PART 10

一张学习地图

这张图把你的成长路径压成四层：产品目标、工程地图、AI 能力、上线验证。可以导出成 PNG，放进你的学习资料或项目资料里。

这不是装饰图，而是你未来跟 AI 协同的检查顺序：先讲目标，再看工程，再用 AI，最后上线验证。

PART 11

常用术语表

下次你看到陌生词，先来这里查。能用自己的话解释这些词，你的 AI Coding 能力就会稳很多。

API

前端和后端之间的功能接口。前端说“我要登录”，后端通过 API 返回登录结果。

Worker

后台执行任务的程序。适合处理耗时、可排队、可重试的工作，比如调用 AI 执行复杂任务。

仓库

代码、文档、配置和历史记录的集合。一个项目可以一个仓库，也可以多个仓库。

Monorepo

一个仓库里放多个应用和包。早期平台项目常用，方便统一改协议、前后端一起验证。

暂存区

Git 里准备进入下一次提交的文件清单。它不是最终历史，只是提交前的选择区。

提交

一次明确说明的版本快照。好提交应该能回答“改了什么，为什么改”。

分支

并行工作线。新功能在分支上做，验证后再合入主线，降低直接破坏稳定版本的风险。

推送

把本地提交同步到远端仓库，让团队和部署系统能看到这次改动。

Pull Request

请求把一个分支合并到另一个分支。通常会做代码审查、测试检查和变更说明。

部署

把代码发布到可访问环境。部署不是结束，上线后还要看日志、监控和用户路径。

域名与 HTTPS

域名是用户访问地址，HTTPS 是加密访问。没有 HTTPS，正式产品会显得不可信，也有安全风险。

环境变量

不同环境下的配置，比如数据库地址、API Key、模型供应商。密钥不能写死在代码里。

日志

系统运行时留下的记录。出问题时，日志是排查原因的第一现场。

监控

持续观察系统是否健康，比如成功率、错误率、响应时间、worker 队列长度。

模型

生成文本、理解指令、推理任务的 AI 能力核心。产品上要关注质量、速度、成本和稳定性。

上下文

AI 当前能看到的信息窗口。上下文太少会答偏，太多会贵、慢、混乱。

Agent

围绕目标自主拆解、调用工具、观察结果并继续执行的 AI 工作方式。

Skill

把某类任务的方法、模板、工具和注意事项打包起来，让 AI 更稳定地完成重复工作。

MCP

让 AI 连接外部工具和数据源的一类协议思想。产品上可理解为“AI 的工具插座”。

RAG

先检索知识库，再让模型回答。适合企业知识问答、制度查询、流程助手。

Embedding

把文字转成机器能比较相似度的数字表示。它支撑语义搜索和 RAG。

评测

用固定任务和标准判断 AI 产品是否稳定。没有评测，只能靠感觉判断质量。

POC / Spike

用最小实验验证关键技术假设。比如先验证某个 AI 执行内核能不能被平台稳定调用。

回滚

上线失败时退回到上一个稳定版本。任何重要上线都应该提前知道怎么回滚。

Codex

面向真实项目的 AI Coding 工作台。适合读代码、改文件、跑验证、整理变更证据，也适合复杂平台项目的小步推进。

Qoder

国内环境里更适合先上手的 AI Coding 工具。适合从静态页、小工具、插件说明和项目拆解开始，把第一条闭环跑通。

Claude Code

偏终端协作的 AI Coding 工具。适合愿意进入命令行和工程目录的人，用来读项目、改代码、跑命令和处理开发任务。

终端 / 命令行

用文字指令操作电脑和项目的窗口。产品经理不用背命令，但要知道它常用来启动项目、运行测试、查看日志和发布上线。

Cloudflare Pages

把静态网页发布到线上地址的服务。比如一个静态课程页发布到 pm-ai-coding-course.pages.dev，就是静态页面的上线入口。

Canvas 转 PNG

在网页里用代码画图，再转成图片。公众号 HTML 常用它生成头图、金句图和名片，避免复制到后台后样式散掉。

P0 闭环

产品最小但完整的一条主路径。比如用户创建智能体、发起任务、后台执行、前端看到结果，这比堆很多半成品功能更重要。

验收证据

证明功能真的完成的材料，比如截图、可访问地址、测试结果、日志、变更文件和未验证风险。AI 说“好了”不算证据。