PART 1
为什么这套经验值得听
这不是“我觉得 AI 很厉害”的空泛判断，而是接近一年独立 AI Coding 之后，尤其最近一周高强度实战里沉淀出来的经验。 数据不能证明每个判断都绝对正确，但能说明一件事：这些原则来自真实生产，不是旁观者评论。
最近一周的两条曲线
代码提交告诉你“产出了多少工程痕迹”，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 会话日志，按“全流程智能体平台 / Qoder / apps/api / apps/worker”等项目关键词粗筛并按会话最大累计值归并。 它适合作为“实战强度”的证据，不适合作为精确成本核算。
对没有工程基础的人来说，这些数字的意义不是炫耀“写了很多代码”，而是说明： 产品经理已经可以通过 AI 进入真实软件生产线。但越能生产，越需要懂流程、懂概念、懂验收。
PART 2
我的 AI Coding 实践宗旨
这不是一份“你会不会写代码”的评分表，而是一份从真实协作里长出来的方法论。 如果一个产品经理过去能写 PRD、做原型、盯交付，那么在大模型时代，完全可以把手伸进软件生产现场。 但前提是：要尊重工程，不迷信 AI，也不把自己的不懂包装成战略。
一句话宗旨
AI Coding 的核心，不是产品经理亲手写出每一行代码，而是用产品判断组织 AI 的工程产能： 把目标说清、把边界框住、把风险摊开、把结果验实，然后让代码真正服务业务。
从轻量内容到复杂平台
过去这段时间的任务跨度很大：最简单的是静态页面和公众号 HTML，往前一步是插件、Skill 和自动化工具， 最复杂的是平台型产品。复杂度不同，协作方法也必须不同。不能用做海报的节奏做平台， 也不必用平台级流程拖慢一个当天就该上线的页面。
先定义产品结果，再谈代码实现
AI 很擅长执行，但它不天然知道什么叫“有用”。产品经理要先讲清用户、场景、动作、成功结果和不可接受的失败。 代码只是这些判断的落地形式。
复杂度决定协作方式
静态页可以快，公众号 HTML 可以美，插件要可复用，平台产品必须讲架构、权限、数据、部署、监控和回滚。 任务越复杂，越不能只追求“先跑起来”。
产品经理的优势不是语法，是判断
你不一定会写 TypeScript、部署 Nginx 或设计数据库，但你能判断用户是否需要、路径是否顺、成本是否值得、 风险是否可接受。这些判断是 AI 替代不了的。
承认不懂，比假装懂更高级
不懂 worker、Git、仓库、部署很正常。危险的不是不懂，而是不问、不验、不要求 AI 解释。 好的 AI 协作，应该允许产品经理把工程黑箱一点点拆开。
所有 AI 产出都要回到证据
AI 说“完成了”没有意义。真正的完成是：能打开、能操作、能复现、测试通过、部署可访问、失败路径能解释。 没有证据，就只是一次漂亮的聊天。
越是大产品，越要把 AI 关进流程
平台型产品不是靠一次灵感写出来的。AI 必须在需求、分支、测试、文档、部署和监控这些流程里工作， 否则越写越快，失控也越快。
不同任务，不同节奏
写公众号和做静态页，重点是表达、排版、视觉和快速发布；做插件和 Skill，重点是把一次经验沉淀成可复用能力； 做平台产品，重点是架构边界、数据流、权限、稳定性和长期维护。
别等“学会编程”再开始
最好的入门方式不是先啃完一门语言，而是从一个真实小任务开始：做一个页面、改一个表单、生成一篇可发布 HTML、 封装一个小工具。每次做完都复盘：我说清了什么，AI 猜错了什么，我验收了什么。
OK，从一个小作品开始
不要一上来就做平台。先做一个能发布的页面、一篇能转发的公众号 HTML、一个能重复使用的小工具。 小作品会逼你经历完整闭环：需求、生成、修改、预览、发布、反馈。
OK，让 AI 写代码，但你必须管验收
你可以不懂每一行代码，但必须知道用户路径是否走通、页面是否能打开、输入错误时有没有提示、 上线后有没有地址和证据。AI 负责生产，你负责验真。
OK，把内容工作也工程化
公众号、报告、海报、课程页不只是“写文案”。它们可以变成 HTML、模板、组件、Canvas 图片和一键复制工具。 这会让内容生产从手工排版变成产品化流程。
OK，把重复经验封装成插件
如果一个任务你做了三次，就应该考虑封装成 Skill、插件、脚本或流程模板。 AI Coding 的价值不只是完成一次任务，而是把方法沉淀下来，下次更快、更稳。
OK，挑战复杂平台，但必须拆阶段
平台型产品可以用 AI 推动，但不能一口吞。先做 POC，再做 P0 闭环，再补权限、数据、监控、部署和安全。 每一阶段都要有可验证产物。
OK，不懂技术，但不要放弃追问
你可以直接问：这个文件负责什么？为什么需要 worker？这次改动怎么回滚？哪个风险还没验证？ 追问不是显得外行，而是在建立自己的工程判断力。
这份课的真正立场是：AI Coding 会让更多非工程背景的人进入创造现场，但进入现场不等于可以无视工程。 产品经理未来最值钱的能力，是把业务判断、工程常识和 AI 执行力组织成一个稳定闭环。
PART 3
先看传统软件研发流水线
软件不是从“写代码”开始，也不是写完代码就结束。传统研发流水线本质上是一条把不确定想法变成稳定线上产品的生产线。 AI Coding 没有推翻这条线，它只是把其中很多环节提速了。越是复杂产品，越要先看清这条线。
机会与问题
先确认为什么要做：用户是谁，痛点是什么，业务上值不值得投入。
产品经理主导：决定做不做。需求定义
把模糊想法写成可执行需求：目标、范围、用户故事、成功标准、暂不做什么。
AI 可辅助：整理 PRD、拆用户故事。原型与验收
画出页面和流程，提前定义正常路径、异常提示、空状态和验收标准。
关键动作：先说清“怎么算完成”。技术方案
决定前端、后端、数据库、worker、第三方服务、部署方式和核心风险。
产品经理要问：哪些是事实，哪些是假设。任务拆解
把大目标拆成小任务：页面、接口、数据表、后台任务、测试、文档、部署。
AI 最适合：把大需求拆成可交付清单。开发准备
准备仓库、分支、依赖、环境变量、测试数据和本地启动方式。
这里会出现：repo、branch、env。编码实现
写前端页面、后端 API、worker 执行逻辑、数据库读写和适配层。
AI 很强，但必须被边界和验收牵引。本地联调
确认页面能打开、接口能通、数据能保存、worker 能跑、错误能暴露。
一句话：不要把没跑通的东西叫完成。测试与审查
用自动测试、手动验收、代码审查确认没有明显回归和安全风险。
这里会出现：test、review、PR。构建与部署
把本地代码打包，发布到测试环境或生产环境，让用户能通过地址访问。
这里会出现：build、deploy、domain。监控与告警
上线后观察错误率、响应时间、任务失败、成本、日志和用户反馈。
上线不是终点，是开始暴露真实问题。复盘与迭代
基于数据和反馈决定继续优化、砍掉、重构、扩展，进入下一轮循环。
产品经理主导：判断下一步价值。先把“为什么做”和“做到哪”讲清楚
不要从“帮我写个接口”开始，而是从问题、用户、场景、目标和验收开始。 AI 越强，越需要一个清楚的上游输入，否则它只是更快地跑偏。
AI 不是替代流水线，而是加速每一站
AI 可以帮你写 PRD、画页面、拆任务、写代码、补测试、查日志、写文档。 但需求取舍、风险接受、上线节奏和最终验收，仍然要有人负责。
越复杂，越要慢半拍设计流程
静态页可以快速发布，插件要考虑复用，平台产品必须把权限、数据、worker、监控和回滚纳入设计。 不是所有任务都配同一套流程。
这就是后面所有概念的牵引线：Git 管的是开发准备到审查，API 管的是前后端协作，worker 管的是后台执行， 测试和部署管的是上线可信度，监控管的是上线后的真实世界。
PART 4
沿着流水线解释核心概念
技术概念不应该一个一个死记。先把它们放回研发流水线里： 哪些出现在开发准备，哪些出现在编码实现，哪些服务于联调测试，哪些决定上线后的稳定性。 下面尽量用白话讲，先听懂“它像什么”，再记住“它解决什么问题”。
1. 前端、后端、API、数据库是什么
这四个词可以先用餐厅来理解：前端像菜单和餐桌，后端像后厨，API 像服务员传单， 数据库像仓库和账本。用户点菜时看不到后厨，但没有后厨和账本，餐厅就跑不起来。
前端
用户能看到和点击的界面。比如登录页、聊天框、按钮、表格。你的平台里主要是 apps/web。
后端
负责真正办事：判断能不能登录、有没有权限、数据存哪里、任务交给谁。你的平台里主要是 apps/api。
API
前端和后端说话的固定通道。就像前台不能直接冲进后厨，只能按规则下单：登录、创建 Agent、发送消息、查状态。
数据库
长期保存东西的地方。账号、配置、任务、消息、运行记录都放这里。没有数据库，系统重启后就像餐厅账本丢了。
2. worker 到底是什么
worker 是“后台执行员”。前端发出任务，API 负责登记和分派，worker 在后台真正执行耗时动作： 调用 Qoder、跑任务、处理文件、更新状态、写日志。
举个例子：用户点“生成一个完整方案”，页面不应该卡住十分钟。API 先说“收到”，worker 在后台慢慢干活， 干完再把结果和状态送回来。
为什么需要 worker
因为 AI 任务可能跑很久，不能让用户页面一直卡住等结果。像外卖平台不会让你站在厨房门口等。
worker 和 API 的区别
API 像前台接待，worker 像后台处理。API 要快，worker 可以慢慢干重活。
你的项目对应
apps/worker 接收平台协议任务，再通过 Qoder Adapter 去执行。
产品问题
你要问：任务排队吗？失败重试吗？用户能看到进度吗？中断后能恢复吗？
3. 协议、SDK、Adapter、Runtime 是什么
这组词听起来很技术，其实都和“不同系统怎么配合干活”有关。你可以把它们理解成： 说话格式、工具包、翻译官和发动机。
协议
约定好的说话格式。比如快递单必须有收件人、地址、电话；平台任务也必须有类型、输入、状态、产物。
SDK
别人提供的工具包。就像买家具附带螺丝刀和说明书，让你更容易使用对方能力。
Adapter
翻译官。你平台说一套话，Qoder 说另一套话，Adapter 负责互相翻译。
Runtime
真正跑任务的发动机。页面和 API 都不是发动机，你的架构里，复杂 AI 执行尽量交给 Qoder Runtime。
4. 本地、测试、生产、上线是什么
这四个词对应“东西在哪里跑”。本地像厨房试菜，测试环境像内部试吃，生产环境像正式开店， 上线就是把菜端给真实客人。
本地
开发者电脑上的运行环境，适合快速试错。坏了只影响自己，不影响真实用户。
测试环境
给团队验证功能的环境。像彩排，尽量接近真实，但台下还不是正式观众。
生产环境
真实用户访问的环境。这里不能随便试错，要能监控、回滚、排查。
上线
把通过验证的代码发布到真实可访问地址。上线不是“发出去就完”，还要看日志和监控。
5. AI 产品里常见的 AI 概念
AI 产品不是只接一个聊天模型。真正做产品时，你会同时遇到模型、上下文、工具、Agent、知识库和评测。 它们分别管“会不会答、看到了什么、能不能动手、能不能连续干活、懂不懂企业知识、稳不稳定”。
模型
负责理解和生成内容的大脑。像不同员工，有的写作强，有的代码强，有的便宜快，有的贵但稳。
上下文
AI 当前能看到的信息。就像你开会前给它的材料，没放进材料包的东西，它就可能不知道。
工具调用
AI 不只聊天，还能动手调用搜索、文件、浏览器、部署等工具。像员工不只出主意，还能打开系统办事。
Agent
能围绕目标连续工作的 AI。它会拆任务、调用工具、看结果、再继续，不是只回答一句话就结束。
RAG
先翻资料，再回答问题。比如问公司制度，AI 先去知识库找原文，再根据原文回答，减少胡编。
评测
给 AI 做考试。用一批固定题目和评分标准看它稳不稳。没有评测，就只能靠感觉说“好像还行”。
6. 日志、监控、告警为什么重要
AI 产品失败时，不一定是代码崩了。可能是模型慢、token 超限、第三方接口变了、用户输入太长、worker 队列堵了。 日志负责回答“发生了什么”，监控负责回答“现在是否健康”，告警负责在坏事扩大前叫醒人。
- 产品经理要看：成功率、耗时、失败原因、用户等待时间、产物质量。
- 工程师要看：错误堆栈、请求 ID、服务状态、资源占用、重试次数。
- AI 产品额外要看：模型调用成功率、成本、上下文长度、工具调用链路。
PART 5
Git：你必须懂的版本管理
在研发流水线里，Git 主要管“开发准备、编码实现、测试审查、合并发布”这几站。 它不只是程序员的工具，而是项目的“时光机”和“交接单”。你不用记命令，但要知道每个状态意味着什么。
工作区
AI 或人刚改完的文件。还没有正式记录。
暂存区
准备打包进下一次提交的文件清单。
提交
一次带说明的版本快照，可以回看和回滚。
推送
把本地提交同步到远端平台。
合并/发布
进入主分支或触发线上部署。
暂存区是什么
暂存区就是“下一次提交的购物车”。工作区里可能改了十个文件，但你可以只把其中五个放进暂存区， 然后提交成一个清晰主题，比如“修复登录错误提示”。
分支是什么
分支就是并行工作线。主分支保持相对稳定，新功能在自己的分支上做，做完验证后再合并。 这样 AI 试错不会直接污染主线。
远端仓库是什么
远端仓库通常在 GitHub、GitLab、Gitee 这类平台上。它是团队共享代码和触发部署的地方。 本地电脑坏了，远端还在。
Pull Request 是什么
Pull Request 是“请求把我的分支合进主分支”。它通常包含改了什么、为什么改、测试结果、代码审查意见。 对 AI Coding 来说，它是最好的质量闸口。
你以后可以这样要求我：先说明当前分支和改动范围，再改代码；改完后展示变更摘要、测试结果和是否需要提交。 这句话能把很多混乱挡在门外。
PART 6
你的项目专属地图
看完流水线，再看当前“全流程智能体平台”的目录就会清楚很多： 每个目录都对应研发流水线里的某一类工作。你以后看到这些名字，不需要紧张，它们各自负责一块清楚的事情。
apps/web
用户界面。 登录、看仪表盘、创建 Agent、聊天、管理 Skill、看监控这些都在这里。
apps/api
产品中台。 前端所有请求先到这里，负责权限、业务逻辑、状态、数据读写和任务分发。
apps/worker
后台执行员。 处理耗时任务，把平台任务交给 Qoder 或其他执行内核。
packages/platform-protocol
内部协议。 规定平台内部如何描述 Agent、任务、事件、产物和状态。
packages/qoder-adapter
Qoder 转接器。 把平台内部协议翻译成 Qoder 能执行的调用方式，也做降级和错误处理。
docs
项目记忆。 记录架构决策、部署说明、Qoder 验证口径和实施计划。
infra
上线机器配置。 包括 Nginx、systemd 等，让服务在服务器上稳定运行。
spikes/qoder-acp-client
验证实验。 用最小成本证明 Qoder ACP/SDK 能不能满足关键假设。
当前更适合单仓库，多应用
你现在做的是平台早期阶段，用一个仓库管理前端、API、worker、协议、适配层和部署文档更合适。 这叫 monorepo，优点是协作快、改协议时前后端能一起改。
当团队和边界变大再拆
如果未来前端、后端、SDK、部署平台分别由不同团队负责，发布节奏也不同，再考虑拆成多个仓库。 现在过早拆仓库，只会增加沟通成本。
PART 7
产品经理的 AI Coding 协同流程
你未来跟 AI 协作，最重要的不是“说得很技术”，而是把研发流水线的上游输入讲清楚： 目标、边界、验收和风险。下面这套流程可以反复用。
先说业务目标
不要一上来要求“写接口”。先说用户是谁、要完成什么动作、成功后页面或数据应该怎样。
限定范围
说明只改哪块，不碰哪块。比如只改登录弹窗，不重构整个认证系统。
要求先读现状
让 AI 先看相关文件、接口、测试和文档，再下结论。工程里最怕凭感觉改。
给验收标准
明确怎样才算完成：页面可见、接口返回正确、测试通过、错误情况有提示、部署地址可访问。
要求解释风险
让 AI 说明可能影响哪些旧功能、有没有数据风险、有没有安全风险、有没有上线注意事项。
最后要证据
完成后不要只听“好了”。要看改了哪些文件、验证了什么、哪里没验证、线上地址是什么。
“你帮我把平台做完整。”
这个问题太大，AI 会自己脑补范围。最后很可能做出很多看似热闹、实际不可控的东西。
“先完成 P0 闭环。”
“用户能登录，创建一个 Agent，发起一次任务，worker 执行 mock/Qoder，前端看到状态和产物。 不做计费、不做多租户高级权限，完成后给我验证路径和未完成风险。”
PART 8
30 天补课路线
你的目标不是学会所有技术，而是建立能和 AI 工程师对齐的最低工程素养。 按这四周学，够你把 AI Coding 提升一个大台阶。
第 1 周：工程地图
先背下研发流水线，再把前端、API、worker、数据库、部署、监控放进同一张图里。
- 每天用自己的话解释 3 个概念。
- 能说清一个用户请求如何从页面走到后端。
- 能看懂当前项目目录的职责。
第 2 周：Git 和交付
理解工作区、暂存区、提交、分支、推送、PR、回滚。
- 每次让 AI 改动前先确认分支。
- 每次改动后要求变更摘要。
- 学习如何阅读一次提交记录。
第 3 周：AI 产品基础
理解模型、上下文、工具、Agent、RAG、评测、成本和安全。
- 给每个 AI 功能写输入、输出、失败路径。
- 为核心任务设计 10 条评测用例。
- 区分“演示效果”和“生产能力”。
第 4 周：上线闭环
学会要求本地验证、测试、预览、部署、监控、回滚说明。
- 每次上线前问 5 个风险问题。
- 每次上线后看访问地址和错误日志。
- 建立自己的产品验收清单。
PART 9
以后直接复制的提示词模板
你可以把下面这些当成“AI 工程协作话术”。越是技术小白，越要用固定模板保护自己。
需求实现模板
我想实现一个功能： 用户是谁： 用户要完成的动作： 成功后的界面或数据结果： 不要改动的范围： 验收标准： 1. 2. 3. 请你先阅读相关代码和文档，告诉我你理解的现状、需要改哪些地方、有哪些风险。确认后直接实现，并在完成后给我变更摘要、验证结果和未验证风险。
排查问题模板
现在出现一个问题： 我看到的现象： 我期望的结果： 发生在哪个页面或流程： 最近改过什么： 是否影响真实用户： 请按“复现、定位、最小修复、验证、风险说明”的顺序处理。不要先大改，先找根因。
上线前检查模板
请帮我做上线前检查： 1. 当前分支是什么？ 2. 这次改了哪些文件和功能？ 3. 本地构建和测试是否通过？ 4. 有没有环境变量、密钥、数据库迁移或部署配置变化？ 5. 如果上线失败，怎么回滚？ 6. 上线后我应该看哪个地址、哪些日志、哪些指标？
学习解释模板
请用产品经理能听懂的话解释这个技术概念： 概念名： 它解决什么问题： 在我们当前项目里对应哪个文件或模块： 如果它坏了，用户会看到什么： 我作为产品负责人需要问哪 3 个问题：
PART 10
一张学习地图
这张图把你的成长路径压成四层：产品目标、工程地图、AI 能力、上线验证。 可以导出成 PNG，放在你的项目资料里。
这不是装饰图，而是你未来跟 AI 协同的检查顺序：先讲目标，再看工程，再用 AI，最后上线验证。
PART 11
常用术语表
下次你看到陌生词，先来这里查。能用自己的话解释这些词，你的 AI Coding 能力就会稳很多。
前端和后端之间的功能接口。前端说“我要登录”，后端通过 API 返回登录结果。
后台执行任务的程序。适合处理耗时、可排队、可重试的工作，比如调用 AI 执行复杂任务。
代码、文档、配置和历史记录的集合。一个项目可以一个仓库，也可以多个仓库。
一个仓库里放多个应用和包。早期平台项目常用，方便统一改协议、前后端一起验证。
Git 里准备进入下一次提交的文件清单。它不是最终历史，只是提交前的选择区。
一次明确说明的版本快照。好提交应该能回答“改了什么，为什么改”。
并行工作线。新功能在分支上做，验证后再合入主线，降低直接破坏稳定版本的风险。
把本地提交同步到远端仓库，让团队和部署系统能看到这次改动。
请求把一个分支合并到另一个分支。通常会做代码审查、测试检查和变更说明。
把代码发布到可访问环境。部署不是结束，上线后还要看日志、监控和用户路径。
域名是用户访问地址，HTTPS 是加密访问。没有 HTTPS，正式产品会显得不可信，也有安全风险。
不同环境下的配置，比如数据库地址、API Key、模型供应商。密钥不能写死在代码里。
系统运行时留下的记录。出问题时，日志是排查原因的第一现场。
持续观察系统是否健康，比如成功率、错误率、响应时间、worker 队列长度。
生成文本、理解指令、推理任务的 AI 能力核心。产品上要关注质量、速度、成本和稳定性。
AI 当前能看到的信息窗口。上下文太少会答偏，太多会贵、慢、混乱。
围绕目标自主拆解、调用工具、观察结果并继续执行的 AI 工作方式。
把某类任务的方法、模板、工具和注意事项打包起来，让 AI 更稳定地完成重复工作。
让 AI 连接外部工具和数据源的一类协议思想。产品上可理解为“AI 的工具插座”。
先检索知识库，再让模型回答。适合企业知识问答、制度查询、流程助手。
把文字转成机器能比较相似度的数字表示。它支撑语义搜索和 RAG。
用固定任务和标准判断 AI 产品是否稳定。没有评测，只能靠感觉判断质量。
用最小实验验证关键技术假设。你的 Qoder ACP 验证就是典型 spike。
上线失败时退回到上一个稳定版本。任何重要上线都应该提前知道怎么回滚。