给产品经理的真实评估与工程补课，2026-05-22 版

你已经会指挥 AI 做项目，但还需要补上工程地图。

这份课不是把你变成程序员，而是让你变成更强的 AI Coding 负责人： 知道该问什么、该验什么、哪里不能拍脑袋、什么时候让 AI 继续做、什么时候必须停下来确认。

先看评价 开始扫盲

PART 1

你的 AI Coding 能力评价

我会说得直接一点：你不是“完全不会”，你是“产品感很强，工程词典不完整”。 这两者差别很大。前者会乱指挥，后者可以通过一套固定学习路径快速补齐。

一句话评价

你已经具备 AI Coding 的产品负责人雏形：能给方向、能问边界、能推动从想法走到项目结构。 但你还不能独立判断工程方案是否稳，尤其是 Git、部署、后端分层、worker、测试和生产风险。

证据

这周协同已经产出了工程骨架

当前项目里已经有 apps/web、apps/api、apps/worker、 packages/platform-protocol、packages/qoder-adapter、 infra、docs 和 spikes。这说明协同已经进入“产品工程化”阶段， 不是停留在页面原型或一次性脚本。

强项 1

你能抓住产品方向

你没有只说“帮我写代码”，而是明确了产品名、部署目标、复用旧前端、后端轻量中台、Qoder 适配层等方向。 这是产品经理最重要的价值。

强项 2

你知道要区分事实和假设

你强调 Qoder 能力要区分“官方已验证”和“需要 POC 证明”。这说明你有风险意识， 已经开始用产品决策方式约束 AI。

强项 3

你愿意暴露自己的不懂

这是 AI Coding 里非常稀缺的能力。你说清楚自己不懂 worker、Git、仓库，这会迫使 AI 用可解释的方式工作， 不会默认你能看懂所有工程暗语。

短板 1

工程对象还没有坐标

你现在容易把“前端、API、worker、数据库、部署、域名、仓库”听成一团。 一旦 AI 说错，你很难第一时间发现它在哪一层错。

短板 2

验收标准还不够硬

AI 写完代码不等于事情完成。你需要习惯要求：本地能跑、测试通过、页面可访问、失败路径可解释、上线地址可验证。

短板 3

Git 与上线链路薄弱

暂存区、提交、推送、分支、Pull Request、回滚这些概念不清楚时，项目越大越容易失控。 你不必亲手敲命令，但必须知道每一步的意义。

最实用的成长目标：你不需要成为“会写所有代码的人”，你需要成为“能让 AI 工程师交付可验证结果的人”。 这就是产品经理做 AI Coding 的核心能力。

PART 2

先建立工程世界地图

技术概念不应该一个一个死记。你要先知道它们分别属于哪一层： 用户看到的、产品中台处理的、后台执行的、数据保存的、上线承载的、AI 推理增强的。

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

用户能看到和点击的界面。你的平台里主要是 apps/web。

后端

负责业务规则、权限、数据读写和任务调度。你的平台里主要是 apps/api。

API

前端和后端说话的接口。可以理解为“产品功能菜单”：登录、创建 Agent、发送消息、查状态。

数据库

长期保存账号、配置、任务、消息、运行记录的地方。没有数据库，系统重启后很多状态会丢。

2. worker 到底是什么

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

为什么需要 worker

因为 AI 任务可能跑很久，不能让用户页面一直卡住等结果。

worker 和 API 的区别

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

你的项目对应

apps/worker 接收平台协议任务，再通过 Qoder Adapter 去执行。

产品问题

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

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

系统内部约定的“说话格式”。比如一个任务必须包含任务类型、输入、状态、产物。

SDK

别人提供的一套工具包，让你的系统能更方便地调用它的能力。

Adapter

翻译器。把你平台的私有协议翻译成 Qoder 能听懂的调用方式。

Runtime

真正跑任务的执行内核。你的架构里，复杂 AI 执行尽量交给 Qoder Runtime。

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

开发者电脑上的运行环境，适合快速试错，坏了影响小。

测试环境

给团队验证功能的环境，尽量接近真实，但不承载正式用户。

生产环境

真实用户访问的环境。这里的改动要谨慎，要能监控、回滚、排查。

上线

把通过验证的代码发布到真实可访问地址。上线后还要看日志和监控。

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

负责理解和生成内容的大脑。不同模型擅长点不同，成本、速度、稳定性也不同。

上下文

AI 当前能看到的信息。上下文不等于永久记忆，没给它看的东西它就可能不知道。

工具调用

AI 不只聊天，还能调用搜索、文件、浏览器、部署等工具，把想法变成动作。

Agent

能围绕目标拆解任务、调用工具、观察结果、继续推进的一类 AI 工作方式。

RAG

先从知识库找资料，再让模型回答。适合企业文档、流程制度、产品知识。

评测

用一批固定题目和标准看 AI 是否稳定。没有评测，AI 产品很难规模化。

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

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

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

PART 3

Git：你必须懂的版本管理

Git 不只是程序员的工具。对 AI Coding 来说，Git 是项目的“时光机”和“交接单”。 你不用记命令，但要知道每个状态意味着什么。

工作区 AI 或人刚改完的文件。还没有正式记录。
暂存区 准备打包进下一次提交的文件清单。
提交 一次带说明的版本快照，可以回看和回滚。
推送 把本地提交同步到远端平台。
合并/发布 进入主分支或触发线上部署。
核心解释

暂存区是什么

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

核心解释

分支是什么

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

核心解释

远端仓库是什么

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

核心解释

Pull Request 是什么

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

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

PART 4

你的项目专属地图

这部分把当前“全流程智能体平台”的目录翻译成人话。你以后看到这些名字，不需要紧张，它们各自负责一块清楚的事情。

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 5

产品经理的 AI Coding 协同流程

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

Step 1

先说业务目标

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

Step 2

限定范围

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

Step 3

要求先读现状

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

Step 4

给验收标准

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

Step 5

要求解释风险

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

Step 6

最后要证据

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

少这样问

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

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

改成这样问

“先完成 P0 闭环。”

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

PART 6

30 天补课路线

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

第 1 周：工程地图

把前端、API、worker、数据库、部署、监控放进同一张图里。

  • 每天用自己的话解释 3 个概念。
  • 能说清一个用户请求如何从页面走到后端。
  • 能看懂当前项目目录的职责。

第 2 周：Git 和交付

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

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

第 3 周：AI 产品基础

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

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

第 4 周：上线闭环

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

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

PART 7

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

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

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

请你先阅读相关代码和文档，告诉我你理解的现状、需要改哪些地方、有哪些风险。确认后直接实现，并在完成后给我变更摘要、验证结果和未验证风险。
排查问题模板 
现在出现一个问题：
我看到的现象：
我期望的结果：
发生在哪个页面或流程：
最近改过什么：
是否影响真实用户：

请按“复现、定位、最小修复、验证、风险说明”的顺序处理。不要先大改，先找根因。
上线前检查模板 
请帮我做上线前检查：
1. 当前分支是什么？
2. 这次改了哪些文件和功能？
3. 本地构建和测试是否通过？
4. 有没有环境变量、密钥、数据库迁移或部署配置变化？
5. 如果上线失败，怎么回滚？
6. 上线后我应该看哪个地址、哪些日志、哪些指标？
学习解释模板 
请用产品经理能听懂的话解释这个技术概念：
概念名：
它解决什么问题：
在我们当前项目里对应哪个文件或模块：
如果它坏了，用户会看到什么：
我作为产品负责人需要问哪 3 个问题：

PART 8

一张学习地图

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

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

PART 9

常用术语表

下次你看到陌生词，先来这里查。能用自己的话解释这些词，你的 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

用最小实验验证关键技术假设。你的 Qoder ACP 验证就是典型 spike。

回滚

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