软件公司的岗位地图：一个人用 AI 扮演整个团队

0030 秒速览：先拿这三句话和一张索引走

读完这一篇，你能回答一个很多新手问错的问题：你想用 AI 一个人做出一个网站或一个小工具，为什么总被「PM（产品经理）、前端、后端、QA（测试）、CI/CD（自动测试与自动发布）」这些词挡在门外？答案是——这些词不是门槛，是一张分工地图。看懂它，你就知道每一件活该交给 AI 的哪一轮、以及哪几件活 AI 根本接不住、必须你自己扛。

速览：三节就能拿到主要价值

如果你只有 15 分钟，按这个顺序读三节就够：01 岗位到底是什么（拿到那把拆解用的刀）→ 08 哪些判断不能外包给模型（本文最该记住的一节）→ 09 最小例子（看着一个需求被七个岗位接力走完，每一关都有能直接抄的口令）。其余章节按需要回来查。

按你的处境直接看这节

这张表是全文的入口。先找到你现在的位置，直接跳过去，不必从头读。

本文给你的一条可操作路径

01岗位到底是什么：四个零件，不是一个头衔

这一节要给你一把刀：看完之后，任何一个岗位名字丢过来，你都能把它切开，看清里面到底装了什么。

一句话版本：岗位是「一类活」的打包，不是「一个人」

日常说话时，「岗位」约等于「一个职位、一份工作、一个人」。但在这张地图里，它是一个更小、更好用的单位：

换个说法：岗位不是「坐在那个位子上的人」，而是「那个位子上必须做对的事」。人走了，活还在；活可以被交给别人，甚至可以交给 AI——但「判断」和「验收」这两件事的归属，决定了你是不是还在掌控之中。

把任何一个岗位拆开，都是同样四个零件

下面拿两个差别极大的岗位对照一下——一个是写文档的产品经理，一个是挑毛病的测试工程师。零件是同一套，只是内容完全不同。

为什么「判断」才是岗位真正的内核

你有没有想过：两个产品经理，坐在同一个位子上、用同一套模板，产出为什么会差十倍？

差别不在打字速度，在问不问、问什么、什么时候停下来不问了。同一句「帮我做个记账工具」，差的产品经理直接把它抄给团队；好的产品经理会先反问：只有你和三个朋友用，还是可能几十人？（这决定了要不要做登录）只记「谁欠谁多少」，还是要按饭局分组、自动平摊？（这决定了复杂度）换台手机账还在吗？（这决定了要不要数据库）

这些问题的答案，AI 猜不出来——因为它不认识你的朋友、不知道你们怎么吃饭、不知道你介意什么。它能做的是把这些问题一次一个地问出来，你负责回答。这就是「判断」的分工方式：AI 负责问全，你负责拍板。

这套拆法对你到底有什么用：它把「头衔」变成了「可以下指令的东西」

如果你盯着「我要招一个产品经理」或者「我得先学会做产品」，这个门槛高得没边。但换成四个零件看：

• 你不需要「一个产品经理」，你需要的是一句能触发「追问需求」这个行为的口令（09 第 1 关 有现成的），加一份你自己认得出的验收标准（12 有现成的清单）。
• 你不需要「一个测试团队」，你需要的是让人列出最容易出错的八种情况，然后自己按其中三条亲手点一遍。
• 你不需要「一个运维」，你需要的是一份「出事怎么退回上一版」的步骤，并且发布前已经确认过退路存在。

一句话：能被写成口令的零件，可以外包；只能靠你的处境回答的零件，外包不了。这一条会在 08 展开成一张表。

一个类比，以及它在哪里失效

用一家奶茶店来感受这条流水线：进料口是用户的声音；中段有人把口味定下来、有人把配方变成能操作的步骤；出餐前有人试喝；开门后有人盯着机器别停摆、坏了马上修。这四段和人打交道的方式，跟软件公司几乎一样——都能对上「有输入、有加工、有质检、有售后」这四个结构。

02它最容易被当成什么：四个想当然

这个概念之所以容易理解错，是因为「岗位」这个词你天天在用，而日常用法和这里的用法正好差一层。下面四个想当然，是新手最常卡住的地方——它们都很自然，也都很贵。

错想一：岗位 = 一个人。于是得出结论「我缺人，所以我做不了」

这是最贵的一个。一旦你把「产品经理」理解成「一个坐在会议室里的人」，那么你一个人做项目时，第一反应就是「我没有产品经理，只能自己瞎想」或者「我得先找到这样的人」。

把它换回四个零件就通了：你需要的是一个「追问需求」的动作，加上一份「什么算做完」的清单。这两样东西，一句口令加一次认真回答就能得到——不需要会议室，也不需要多一个人。

但公平地说，反过来也成立：真实公司里之所以要真的招人，不是因为「岗位」必须由人担任，而是因为复杂、严肃、要长期多人维护的系统需要多个人的判断互相制衡（这一点在 08 会讲透）。所以正确理解是：岗位的「活」可以一个人＋AI 全接，岗位的「制衡」接不了。

错想二：岗位 = 一个头衔或职级。于是以为要先「升上去」才配做

「初级工程师 / 高级工程师 / 技术专家 / 总监」——这些是职级，说的是「一个人到了什么水平、拿多少钱、有多少决定权」，不是「一类活」。同一件活（比如「写一个导出报表的功能」），初级和高级做出来的差别在质量与判断，不在活本身。

这个区分对你很实用：你永远不需要「先成为高级工程师」才能让 AI 当高级工程师。你要做的是把「资深」两个字写进口令里——它会影响模型给出的谨慎程度和理由质量（这是行业里被反复观察到的现象，属于行业通行说法，不是硬保证）。你要补的是提问的准头，不是头衔。

错想三：岗位 = 一套黑话。于是跑去背词表

「PRD（产品需求文档）、Sprint（一轮固定长度的开发周期）、CI/CD（自动测试与自动发布）」这些词确实会挡路，但它们是"压缩上下文"的暗号——上下文就是"这次对话里它能看到的所有内容"，黑话的作用是把一长串话压成一个词。它们不是知识本身：说「这个需求进需求池」，意思其实是「这个需求这一版不做，先排队」。

所以背词表是把顺序搞反了：先懂那个场景，词自己就会长在你脑子里。看到一个不认识的词，最有性价比的动作是问 AI 一句：「这个词用大白话解释，再说它是哪个岗位常说的、什么时候用、什么时候别用。」30 秒就能把它变成活的知识。16 的对照表就是为这种查词准备的。

反过来也成立：完全不认识这些词会读不懂教程和 AI 的回答——AI 自己也是用这套词思考的。所以不是「不用学」，而是「别用背的方式学」。

错想四：岗位 = 流程图上的一个方框。于是照抄流程就以为万事大吉

知道「需求 → 设计 → 开发 → 测试 → 上线」这条线，比不知道强很多。但流程图只画了顺序，没画每道关的交付物和验收标准——而那才是这道关存在的理由。

举个具体差别：同一个「加一个分享按钮」，照着流程图走的人会说「先需求、再设计、再开发」，但每一步都没有标准；懂四个零件的人会在第一关就问出「分享给谁、分享到哪、点了之后页面怎么变」，并要求在需求里写下「这版不做分享统计」——这一句「不做」能省掉后面一大半返工。

四个错想共同的根，以及一句纠正

03它怎么运作：交付物在岗位之间接力

上一节把单个岗位拆开了。这一节看它们怎么串起来——一家软件公司真正在运转的东西，是一条交付物接力。

岗位之间传递的不是消息，是交付物

真实的公司里，同事之间当然会说话、会开会。但真正让工作往前走的，是一件能交出去的东西：一份写得清楚的需求、一张很糙的布局草图、一个能打开能点的版本、一张按严重程度排好的毛病清单、一份「出事怎么退回」的步骤表。

为什么强调这一点？因为有交付物，才有验收的可能。你和 AI 之间没有会议室、没有同事帮你盯着，唯一能让你确认「这一步真的过了」的东西，就是你手里那份交付物。所以从那句「帮我做个 X」开始，每一次对话都应该以「交出一件具体东西」为目标，而不是以「聊明白了」为目标。

三圈人：按「离用户多远」排开

先不管具体头衔，一家公司的人可以按离用户的远近分成三圈。这个分法的好处是：看一眼就知道一件事该归谁管。

三圈之外还有一类横向支撑：销售、市场、客服、行政、老板。他们决定「卖给谁、怎么介绍、出了事怎么安抚」，同样重要，但和你一个人用 AI 做东西关系不大——本文只在需要时提一句。

一个功能的一生：七道关

把三圈竖起来看，就是一条流水线。下面这个流程，是「加一个分享按钮」这类小功能在真实公司里的常规走法——你会在 09 看到它的完整演练版。

越小的公司，岗位越少：岗位是「长」出来的

看岗位图最容易被「十几个职位」吓到。真实的规律恰好相反：团队越小，一个人身兼的岗位越多；只有活多到一个人忙不过来时，岗位才一个个裂出来。

另外先分清一件事：互联网大厂、中小公司／创业公司、接别人活的外包公司、你的一人公司，岗位图的粗细并不一样——大厂最细（一个按钮后面都可能有人专门负责），外包公司最看重需求评审与验收，一人公司则所有岗位都是随叫随换的"角色"。本文讲的是小型到中型团队那套骨架：看懂骨架，到哪家公司都认得出它。

把这条接力画成一张你记得住的图

这条接力只有两条规则：不点头，不进入下一棒（这是你的验收权）；出了乱子回上一棒查（改坏了不要从头重写，让 AI 退回去再修）。把这条接力练顺，你就有了一份属于自己的一人公司运营手册。

04岗位、职位、角色、职级、职能：五个词别混

这几个词在日常和工作里被互相替换着用，本来没什么问题。但当你要用它们给 AI 下指令、要判断"这一步该谁负责"时，混用会直接让你下错指令。

先把五个词摆在一张表上

最容易被搞混的一对：岗位 vs 角色

当你对 AI 说「扮演产品经理」时，实际发生的事是：它进入了一种追问需求的行为模式。这就是「角色」——一次工作里临时承担的身份。但一个完整的岗位还包括交付物与验收标准。如果你只要了角色、没要交付物，它就会问一堆问题然后……什么都不交。

「让 AI 扮演角色」和另外三个词差在哪

你在别处还会听到几个相关的说法，它们经常被混着讲，其实是四件不同的事：

新手从这个顺序开始最稳：先手写口令 → 某个角色反复要用再把它存成文件 → 最后才尝试让多个角色对话。别一上来就搭"多智能体团队"，那通常只会得到一个自说自话的独角戏。

一个反向提醒：真实公司里，岗位之间是有摩擦的

真实公司里，产品经理想多加一个功能、工程师说做不完，这种拉扯是故意的——它是质量的来源，逼出"我没想到的坑"。而 AI 一人分饰多角时不会自己跟自己吵：它顺着你、顺着上一个角色往下走。所以"让两个角色互相 review"必须由你下指令触发，不会自动发生（10 有现成的开会口令）。

05第一圈：决定做什么的人（产品经理 / 设计师）

这一圈决定"做什么、长什么样"。真实公司里，产品成败往往在这一圈就定了：代码写错可以改，方向错了白干三个月。

产品经理的一天，其实就是三件事

• 问问题：到底给谁用？这个痛是真的吗？他愿意为它改变习惯吗？（行话叫需求调研、用户访谈）
• 写下来：把想清楚的东西落成别人能照着做的一页纸。
• 排优先级：先做什么、后做什么、砍什么。（行话叫路线图，指未来几版大概做什么的安排）

这三件事不是我的总结，而是行业原文：被广泛采用的敏捷方法（一小块一小块快速交付、随时根据反馈调整方向的做法）说明书《Scrum Guide》（2020 年版）对"产品负责人"的职责写得很直接——他对"让团队交付的价值最大化"负责，并负责把复杂问题整理成一份排好顺序的需求清单。注意"排好顺序"这四个字：它和"收集需求"是两件事。

产品负责人、项目经理：什么时候会多出这两个名字

• 产品负责人（Product Owner，简称 PO）：在采用 Scrum 的团队里，更偏"跟做的人贴身敲定这一版做什么、拍板需求顺序"的那个人。《Scrum Guide》里有一条对你特别有用：产品负责人是一个人，不是一个委员会——它意味着"需求的最终拍板"无法靠开会分摊，必须有一个具体的人扛。
• 项目经理（Project Manager）：更偏"盯进度、协调资源、对外沟通"。小公司里常常由产品经理一个人全包。

你只需要记住：PO ＝ 天天跟做的人敲定"这版做什么"的那个角色。名字怎么叫，不影响你要做的事。

一张表：一个「想法」要过哪几道追问，才算一条「需求」

看懂第二列，你就懂了产品经理的真正价值：他不是在收集答案，他是在辨认哪些问题的答案会改变做法。同一句话「帮我做个记账工具」，差的 PM 直接开工，好的 PM 先问这六条里的三四条。

设计师：UX 管好不好用，UI 管好不好看

• UX（用户体验，User Experience）：管"好不好用"——用户打开软件，几步能找到他要的功能？会不会迷路？这一层的交付物叫线框图（很糙的黑白草图，标着"这块放什么、点了跳去哪"）。
• UI（用户界面，User Interface）：管"好不好看"——颜色、字体、圆角、间距、按钮长什么样。交付物是设计稿。

新手最容易犯的错是跳过线框图直接要成品——那相当于没画草稿就让人盖房子。线框图是这里最便宜的交付物：一张草图改起来一分钟，一个做好的页面改起来一下午。对不会设计的人，AI 是巨大的外挂——让它先用文字把布局和"用户点每一步发生什么"讲一遍，你点头之后再让它生成界面。

这一圈的黑话速览

一份真实的一页需求长什么样（可以直接抄的样板）

上面一问一答攒够了，PM 会把它落成一张一页纸。这是你以后验收 AI"有没有听懂"的参照物：格式不重要，内容到位就行。

# AA 记账 · 一页需求（示例）
## 一句话
做一个让 2~5 个好友出去吃饭后快速平摊、并记得"谁还欠谁"的小工具。
## 给谁用（用户）
我和常一起吃饭的 3~4 个朋友；大家都会用手机，不擅长记账。
## 第一版范围（MVP）
1. 建一个"饭局"，把几笔花费和付款人记进去；
2. 自动算每人该付多少、谁欠谁多少；
3. 微信里能打开，手机看起来正常。
【本版不做】登录、多语言、历史报表、消息通知。
## 验收标准（怎么做完算完成）
- 记一笔 → 金额和付款人存得住：刷新、重开都还在；
- 自动算出的"谁欠谁"数字，我手动核对是对的；
- 手机和电脑打开都不破相；
- 满员的饭局（5 人、10 笔账）也不卡不错。
## 不做清单（防止跑偏）
- 不做自动提醒 / 不做外币 / 不做退款流程。

06第二圈：把它造出来的人（前端 / 后端 / 全栈）

这一圈就是大众口中的"程序员"。你本人不写代码，但弄清"前端／后端／全栈"的差别，是你和 AI 顺畅沟通的地基——让 AI 写哪一部分、出了问题先怀疑哪一部分，全靠这几个词。

用户看得见的一半，和看不见的一半

权威教程 MDN（Mozilla 维护的网页技术文档）把这件事说得非常直白：HTML、CSS、JavaScript 是前端（也叫客户端）语言，由浏览器负责运行，产出用户能用的界面；另有一类叫后端（也叫服务端）语言，跑在服务器上。

• 前端（Front-end）＝看得见的门面：你在浏览器或手机里看到的页面、按钮、动画。它由三种东西搭起来：HTML 是骨架（这一块是标题、这一块是按钮）、CSS 是样式（颜色、排版、间距）、JavaScript 是行为（点了按钮之后发生什么）。再上面还有框架——别人写好的半成品工具箱，前端常见的有 React、Vue。
• 后端（Back-end）＝看不见的厨房：你的手机不直接算账、不直接存数据，而是把请求发给一台常年开机的远程电脑（服务器），由它处理：确认你是谁、做计算、读写数据库（专门存数据的仓库，用户、订单、照片都在里面）、去调别的服务，最后把结果传回前端显示。两边约定好的对话格式叫接口（API）。
• 全栈（Full-stack）＝两边都能写的人。小团队和一人项目几乎都是全栈。

五个带「端」和「栈」的职位，一张表分清

拿一个「打卡」功能，把前端、后端和数据库连起来看一遍

抽象的词最唬人，套一个具体功能就全通了。假设你要做一个"每天打卡"功能：

# 给 AI 的分工口令（示例）
帮我做打卡功能。你当全栈：先做出打卡按钮的页面（前端），
再写保存打卡记录的接口和数据库（后端）。做完后我刷新页面
数据要还在；每一步说明你在改哪个文件。

你最常碰到的研发黑话

五个新手判断题，各有口诀

这些判断题你不需要背结论——把问题原样丢给 AI 当架构师，让它按"最小可行＋一个人维护"给你建议并解释理由。你只要记住一个原则：一切决策都先问"最小的那个方案是什么"，默认选最小。AI 的默认值是"最完整"，你的默认值应该是"最省心"。

按钮点了没反应：先分前后端，再找 AI

把这一圈的知识落到一次真实的故障上，你会发现"岗位分工"在排查时有多好用。假设你的打卡页面做好了，但点"打卡"没反应：

这个"先分前后端、再找 AI"的小动作，就是你的第一个技术判断力——它不需要你会写代码，只需要你知道两半的边界在哪。

07第三圈：兜底的人（测试 / 运维 / 架构师）

这一圈最没存在感，但产品崩不崩、坏没坏、能不能上线，全看它。外行总盯着"写新功能"，这一圈回答的是：改完了会不会弄坏旧的？发出去别人能不能用？挂了谁能先知道、谁能最快救回来？

测试工程师：在用户骂之前，先把毛病找出来

测试工程师（QA，Quality Assurance 的缩写，意思是质量保障）的工作一句话说完：在用户发现之前，先把问题找出来。手段分两类：

• 人工点一遍（手动测试）：像用户一样东点点西点点，专门挑边边角角（行话叫探索性测试、边界情况）。
• 让代码自己检查代码（自动化测试）：写一些"检查脚本"，每次改完自动跑一遍。

五种测试的名字，用一句日常话记住

运维／DevOps／SRE：CI/CD 到底在自动化什么

DevOps 是"开发（Development）和运维（Operations）打通"的一整套做法，维基百科的定义是"软件开发与信息技术运维的整合与自动化"。但它更常被用来指负责"把代码自动送到用户手上、并保证它一直能用"的那类岗位。核心词是 CI/CD：

• CI（持续集成）：你每次改完代码往版本仓库里一推，系统自动跑一遍测试，确认没把别人弄坏——相当于流水线上的自动质检。
• CD（持续交付／持续部署）：测试一过，系统自动把新版本发布到服务器，不用人肉登录服务器敲命令。

这条自动化流水线行话叫流水线（Pipeline）。运维的日常还包括：看监控（用户访问量、报错率）、出事时执行回滚（退回上一个能用的版本）、扛不住时扩容（加机器）。大厂里还有 SRE（站点可靠性工程师），本质是"用工程的方法保证网站尽量不挂"（和用户约定的"一年里最多挂多久"叫 SLA）。

自己运维还是交给托管平台：新手不必二选一

判断自己该走哪条路，一句话就够：这个项目需要一直在线、给很多人用吗？需要，就用托管平台；只在你自己电脑上跑、不需要别人访问，那就连发布都不用做。别把"上线"当成所有项目的必经关卡。

架构师：为什么一个人也需要这个岗位

架构师是资深到一定程度、不主要写代码而决定技术大方向的人：选什么语言和框架、系统拆成几块、每块之间怎么通信、将来人多了怎么扩展（行话叫架构设计、模块划分、技术选型、技术债——技术债指为了赶工留下的"将来要还的利息"，比如乱代码和没测试）。

在你的一人＋AI 团队里，这个岗位是你自己＋问 AI：你定"要做什么、多复杂"，让 AI 出两三个方案让你挑。为什么必须有？因为 AI 很乐意把代码写得又长又绕，而维护成本没人替你扛。从第一天起就问一句："方案 A 和方案 B 各有什么利弊？哪个对一个人维护更省心？"——这个"拍板选简单方案"的动作，就是架构师的核心职责。

上线前必须准备好的三件事

一场事故的剧本：四幕

理论太多记不住？给这一圈配一个迟早会发生的剧本（别慌，它只是最坏情况的彩排，看过就有底）：

这出戏的关键不是"出了事"，而是三个动作你都有准备：有日志可查、能一键回滚、会事后复盘。真出事故时，这三个动作比任何"祈祷别出事"都管用——而它们全是 AI 能替你配好的。

08哪些判断不能外包给模型

这是本文最该慢读的一节。前面七节都在讲"怎么让 AI 顶上岗位"，这一节讲哪几个位置它顶不上——而那正是你的岗位。很多人"一人公司做不起来"，不是不会用 AI，是一直想把下面这四件事交给 AI，而 AI 接不住。

先把话说死：外包不了的是「判断」，不是「劳动」

AI 能在一分钟里产出一份像模像样的需求文档、一份按严重程度排序的毛病清单、一份分步发布清单；它甚至能替你问出你没想到的问题。但它接不住这样一类东西：只有站在你的处境里、并且承担你的后果，才能给出的答案。

四件 AI 接不住的事

把这四条读两遍。它们合起来就是一句话：AI 负责把活干出来，你负责决定值不值得干、干得对不对、出了事算谁的。

一个反直觉的事实：AI 不会自己跟自己吵

真实公司里，产品经理和工程师会互相拉扯：一个说"这个功能必须做"，一个说"做不完、这么做将来会崩"。这种拉扯很烦，但它是质量的来源——它逼出"我没想到的坑"。

AI 一人分饰多角时不会发生这种拉扯：它会顺着你说话，顺着上一个角色往下走。所以你要的"反对声音"必须由你下指令触发（10 有一句现成的开会口令）。

但也要诚实：让两个角色互相 review，你能得到"我没想到的坑"，却得不到真正的责任分摊。最后仍然是你看、你拍板、你承担。

把两种形态摆在一起：变的是什么，没变的是什么

别把「它做得挺快」当成「它做得对」：三个可观察的验证动作

AI 最危险的不是答错，而是答错还很自信。行业里把模型一本正经编造事实的现象叫幻觉（Hallucination）。所以"能跑起来、能自己验证"的结果，永远比"听起来很对"的说法可靠。

三条底线：写进你的规则文件，别靠记性

1. 任何"删除／覆盖／清空数据"的动作，让 AI 先停手问你。
2. 让 AI 改代码前，先确认你的项目已经提交过一次存档——这样才有"后悔药"。
3. 不要给 AI 超出当前项目文件夹的权限。

守住这三条，AI 闯祸的"事故半径"就被压在最小。这三条不是吓唬你，是行业里所有人踩过的坑。

09最小例子：一个需求，按岗位接力走完七关

前面讲的是形状，这一节给你一条可以照着练的完整路径。需求很小：「每周把一些照片自动发给爸妈。」下面每一关都给出三样东西——你实际对 AI 说什么（可直接抄）、这一关在真实公司里对应哪个岗位、你验收什么。这套口令需要"能读文件、能改文件"的 AI 编程代理才完整体验（代理＝能自己读你的项目文件、改代码、跑命令的 AI 工具）；但第 1 关用任何聊天 AI 都能练，见本节的「只用手机会用 AI 也能练的那一关」。

第 1 关 · 需求澄清（对应岗位：产品经理）

# 给 AI 的一句话：让它在动手前先当"产品经理"
我想做一个"每周给爸妈发一次照片的邮箱工具"。动手写代码之前，
请你先扮演产品经理，只向我提问、不要写代码，把需求问清楚
（给谁用、照片从哪来、会不会收到回复、要不要提醒），每次只问一个
问题，我答完你再问下一个，问够 5~8 个就停下，把需求整理成一份
一页纸的"需求文档"。

验：它交出的需求文档里，「每周几点发、发什么、失败怎么办」都写明了，你看得懂并且认同。运行后你会看到一幕典型的公司流程被压缩进几分钟：它开始追问"照片存在哪？""是每天自动发还是你挑好再发？""爸妈收到的是链接还是邮件里的图片？""失败怎么通知你？"——这就是公司在做需求澄清。

如果嫌上面那段太长，先用这句极简版也是同一件事：

我想做个工具，每周自动把照片发给爸妈。动手前先当产品经理，
一次问一个问题，把影响做法的关键点问清楚，最后给我一页需求。

只用手机会用 AI 也能练的那一关

完整的七关需要能改代码的 AI 代理。但第 1 关用任何聊天 AI 都能练，而且它恰恰是新手最该先练熟的一幕：你练的不是 AI，是你自己"把模糊念头变清晰"的能力。换着花样试：同一个想法，今天让它一次问一个问题；明天让它一次把 10 个问题全问了再整理——对比两种问法哪个让你更容易想清楚。

# 推荐再试一次：换一个真实小需求练产品经理
我想做【你真实想要的小工具】。先当产品经理，问我 10 个会影响做法的
问题（可以一次全问，标上①②③）。问完按重要性排序，把最重要的 3 个
结论整理给我，再问我"要不要据此写成一页需求文档"。

第 2 关 · 设计（对应岗位：界面／体验设计师）

现在当设计师。先别写代码，用文字把界面讲给我听：页面分几块、
我第一次用要填什么、平时我每天要看什么。给最省事的第一版方案。

验：你能脑补出界面长什么样，并觉得"这版够用，别加花活"。这一关的产出是最便宜的交付物——一张用文字描述的草图，改起来零成本。新手最容易跳过的就是它。

第 3 关 · 拆解排期（对应岗位：技术负责人）

当技术负责人，把"每周定时把文件夹照片发给爸妈"拆成 3~5 个
小步骤，告诉我每步大概要做什么、哪步风险最高，先别写代码。

验：你看到它打算"先做手动能用的，再做定时自动"，而不是一上来就啃最难的部分。若它没分步，提醒它"按最小可用优先排"。这一关的价值是让你在动手前就看到它的计划。

第 4 关 · 开发（对应岗位：前端／后端／全栈工程师）

好，按你排的顺序一步步来。先做"选一张照片→点发送→爸妈邮箱
能收到"这个最小闭环。每一步做完告诉我改了哪个文件、怎么跑起来，
我确认了你再进入下一步。

验：你照着它给的方法（多半就是一行命令）能把程序跑起来，真的发出了一封测试邮件。这一步跑通，天就亮了一半。注意你此刻的职责不是写代码，而是守着"一次别改太多"。

第 5 关 · 自测（对应岗位：测试工程师）

现在当测试工程师。列出这个功能最容易出错的 6 种情况（比如
没有网络、照片很大、收件人写错、连着发两周），逐个测给我看；
再写一个自动测试，防止以后改动把它弄坏。

验：它列出的情况里有几条是你没想到的，并且"坏了会怎样"都给了处理办法，而不是通篇"没问题"。然后你自己当一次真实用户，亲手点一遍核心流程——这是 AI 替不了的那一步。

第 6 关 · 审查合并（对应岗位：资深同事 / 代码审查）

让 AI 先把这次的改动说明列一遍，再当资深工程师给自己 code
review：有没有隐患、能不能更简单。改完用 Git 提交一次存档。

验：你大概知道"这次一共动了哪些文件"；提交之后你有了后悔药（Git 是代码的版本存档工具，"提交"就是给当前改动拍一张存档照）。

第 7 关 · 上线与观察（对应岗位：运维／DevOps＋产品）

怎么让它"不用开着电脑也能每周自动发"？给我最省事的托管方案
和分步发布清单；并写明：如果哪周没发出去，怎么排查、怎么退回。

验：它给的发布步骤你是能照做的（或干脆建议你换个不需要常开电脑的做法，比如平台的定时任务）；你知道去哪看"这周到底发出去了没"。

请注意：这套对话里你几乎没有写代码，只做了四件事——喊角色、说目标、定范围（先最小闭环）、验收。把这一条路走顺，等于把一家公司的整条流水线装进了你的电脑。

把同一个方法拉长：6 轮对话从零做出并发布一个小工具

换一个需求再走一遍：「睡前待办汇总」——每晚把你白天随手记下的待办，自动汇总成一条消息发给你自己。括号里是 AI 大致会回你什么，方便你对答案。

# 第 1 轮：当产品经理，澄清需求
我想做个"睡前待办汇总"：把白天随手记的待办，晚上自动汇总发给我
自己。先当产品经理，一次一个问题问清影响做法的点，最后给一页需求。
（AI 会问：待办从哪记？用什么记最快？汇总发到哪、几点发？要不要
 标"没做完的"？……）
# 验：先用最简单的——一处记录 + 每晚发一条。别在这时就想要日历同步。

# 第 2 轮：当架构师，对比方案
当架构师，给我两个实现方案对比：方案 A 全用现成工具（记在某个 App
再导出）和方案 B 自己写个程序，各要什么成本、我一个人维护哪个省心？
你推荐哪个？先别写代码。
# 验：你听懂了两个方案的取舍，并亲手拍板"选 B，但先做最小版"。

# 第 3 轮：当工程师，做最小闭环
好，按 B 做最小版：先实现"我往一个文件夹里丢一行行待办文本，它读
出来生成一条汇总消息"这一步就好，别的先别做。每步说明改了哪个文件、
怎么跑。做完我先验你再继续。
# 验：你在本地跑通——丢几行文本 → 程序吐出汇总。真实可感，不是黑箱。

# 第 4 轮：当测试，挑毛病 + 写自测
当测试工程师：列这个程序最容易出错的 5 种情况并逐个验证；再帮我
写个自动测试，防止以后改坏"读文件 → 出汇总"这个核心。
# 验：你故意丢个空文件、中文乱码，看它是否提前发现这些情况。

# 第 5 轮：当资深同事，code review + 提交
当资深工程师给自己 review：哪里能更简单、有没有隐患？没问题就帮我
用 Git 提交一次，提交说明写清楚这次做了什么。
# 验：你有了一条"能退回"的存档；改动记录你大致看得懂。

# 第 6 轮：当运维，让它"每天自己跑"
当运维：有没有办法让它不用我开电脑，每天晚上自动跑一次并发给我？
给我最简单的托管/定时方案和分步发布清单，注明出问题怎么查。
# 验：第二天同一时刻，你真的收到了那条汇总——成了！之后有想法就回第 1 轮。

注意每一轮都满足下一节的六段式：角色＋背景＋一个任务＋产出＋约束＋先列清单。你从头到尾没学过一行语法，只是不断"开一个会、验收一个交付物"——真实软件团队就是这样推进的，你只是把一屋子同事换成了一个任劳任怨的 AI。

10可复制的口令仓库与岗位说明书

这一节是本文最"工具化"的部分：把前面所有方法压成可以直接粘的东西。核心心法是一句话——你不再问 AI「帮我做个软件」，而是问 AI「现在你是某个岗位，做那个岗位该做的事」。角色切得越清楚，产出越像样。

一个通用公式：六段式岗位指令

让 AI 扮演任何岗位，都可以套这个模板（可复制，把方括号里的内容换成你的）：

【角色】你现在扮演【产品经理 / 前端工程师 / 测试工程师 / ...】，是团队里
       最有经验的【该角色】。
【背景】这个项目是【一句话说明做什么】，目前做到【现状：比如已有登录、
       还没有分享功能】。
【任务】这次只做一件事：【具体要 AI 完成的小任务】。
【产出】做完后给我：【一份需求文档 / 改好的代码+改动说明 / 一个能打开的
       页面 / 一份 bug 清单 / 一份发布步骤】。
【约束】不要做【越界的事：不要一次改超过 N 个文件、不要动数据库、
       不要直接部署、不要删我不认识的文件】。不确定就停下来问我。
【做完后】先给我一页"我打算怎么做"的清单，我确认后你再动手。

六段各有用途，一段都别省

可复制的口令仓库：12 句开场白，存着随取随用

下面每一句都能直接发给 AI，是全文方法的浓缩。建议收藏起来：

1. 先当产品经理，把【描述想法】的需求问清楚，一次一个问题，最后给一页需求 + 验收标准。
2. 当设计师，先别写代码，用文字/线框描述界面布局和操作流程，给最省事的第一版。
3. 当架构师，给【要做的功能】出 2~3 个方案对比，从"我一个人维护哪个最省心"的角度推荐一个。
4. 当工程师，把【一个最小闭环】做出来，每步告诉我改了哪个文件、怎么跑，我确认再继续。
5. 当前端，做一个手机电脑都能看的【页面/界面】，先给我能跑的版本。
6. 当后端，实现【存数据/登录/定时发送】，数据要真的存得住、刷新还在。
7. 当全栈，把前后端都做了，端到端跑通【核心动作】到数据落库。
8. 当测试工程师，列这个功能最容易出错的 5~8 种情况并逐个验证，再写自动测试防回归。
9. 当资深工程师，给这次改动 code review：找 bug、隐患、可简化处，按严重程度列。
10. 当 DevOps，用最简单的托管方案帮我把项目配好一键发布，给出分步清单和回滚方法。
11. 当分析师，帮我设计怎么判断这个功能有没有人用：埋哪些点、看哪些指标。
12. 改之前先别动手：列出你打算怎么做的清单，我确认了再执行；涉及删数据/覆盖先停下来问我。

场景索引：你想做的事 → 该让 AI 当谁

刚上手时别想太抽象，直接对着"你想做的事"找人。这张速查表按目的找人，比按岗位表更顺：

让 AI 演「一个团队开会」，自己当评审

熟练之后，你可以让 AI 在同一个会话里切换多个角色互相挑刺——这是真实公司"开会"的廉价版：

现在开一个小会。你先当【产品经理】用 3 条说清这个需求的
验收标准；然后切到【资深工程师】，从技术角度提 3 个"这个需求
哪里不合理/有没有更省事的做法"；最后切回【产品经理】回应
工程师的质疑，给出结论。全程不许写代码。

为什么要这样绕一圈？因为 AI 顺着你说话：你不主动让它"反对自己"，它就一路附和。让两个角色互相 review，等于把"我怎么没想到的坑"逼出来。真实团队里最贵的就是这种碰撞，而它现在只要一句指令。

角色口令「不好使」？先查这两个原因

如果你按上面的方式喊了角色，AI 却还是像没戴帽子一样，八成是下面两个原因之一，而且都很容易修：

再记住一个反直觉的事实：角色不是越多越好。一人＋AI 最常见的翻车，是一口气给 AI 安了六顶帽子还要求它自己开会——它很容易演成一个自说自话的独角戏。新手从"一次一顶帽子＋一关一验收"开始，演熟了再分饰两角。

11把口令固化成项目章程（CLAUDE.md / AGENTS.md）

每轮都贴一遍说明书太累：让 AI 一进项目就自动读

主流 AI 编程工具都有一个机制：把你的规则写成项目文件夹里的一个文件，它每次进入这个项目都会自动读。Claude Code 管它叫 CLAUDE.md，别的工具常叫 AGENTS.md 或 .cursorrules——名字不同，作用一样。

你可以把它当成"贴在你这家公司墙上的公司章程"：它替你回答了第 10 节六段式里的【背景】和【约束】两段，而且你只需要写一次。

一份可以直接抄的章程样例

# 项目：给爸妈的照片周报工具
## 产品章程（给 AI 定规矩）
- 这个项目是我一个人维护，追求简单，能用就好，不要过度设计。
- 技术栈由我拍板，不要擅自引入新框架/新库。
## 默认工作方式
- 每次只改一个功能，改前先列"改动清单"让我确认。
- 任何可能删除/覆盖数据的操作，先停下来问我。
- 代码里加中文注释，关键步骤在对话里用大白话说明改了哪。

你甚至可以让 AI 帮你起草这份章程

不用自己从零写。下面这句可以直接发：

根据我这个项目的目标和我的水平，帮我写一份 CLAUDE.md：
规定你以后每次进这个项目都怎么干活——包括我一个人的维护原则、
每次改动前要先做什么、哪些操作必须先问我。

以后每次新开对话，AI 一进项目就自动"入职"，你就不用反复调教了。

熟练之后：把角色封装成能点名的子代理／技能

当某个岗位的口令你反复要用，可以把它写成一个小文件，之后一句"用产品经理代理审一下这个需求"，它就带着整套说明书上岗，不用每次重贴。这就是 04 里说的子代理／技能。

但顺序别搞反：先手写口令，发现某个角色反复要用，再把它封装。一上来就搭一套"多角色系统"，通常只会得到一堆你既看不懂、也用不上的空壳。

12验收：这一关天然属于你

前面每一关都提到"你验什么"。这一节把验收本身当成一个岗位来讲——它是唯一一个AI 再强也顶不上的位置。

为什么这一步必须你自己来

公司里每个环节都有一个验收标准，行话叫"验收条件"或"完成的定义"：一句话说清"什么算做完"。你如果不懂什么是好，AI 给你什么你都只能"哦"——就像你没法验收一碗自己不会做的面。反过来讲：AI 可以做技术性检查（有没有 bug、安不安全），但验收"这功能到底是不是我要的"永远替代不了你，因为"要什么"只有你知道。你不写代码没关系，但你要会当"试用者"：亲手点一遍、看数据在不在、问自己"如果用户这么做会怎样"——这需要的不是代码能力，是较真。

一份通用验收清单（存成「验收清单.md」，每次打勾）

把下面这份清单存成你电脑上的一个文件，每次让 AI 改完东西，你对着它打勾。它相当于把"测试＋你自己"合并成了一份你不用背的检查表：

# 验收清单（每次 AI 改完东西后，逐条打勾）
[ ] 这是不是我要的？——重读需求/验收标准，别被花哨效果带偏。
[ ] 核心动作跑通了吗？——亲手从"进页面"到"完成关键动作"点一遍。
[ ] 数据是真的吗？——刷新页面、关掉重开，数据还在吗？
[ ] 边界试了吗？——故意输入空的、超长的、错误的（空邮箱、超大字、断网再点）。
[ ] 会弄坏别的吗？——旧功能还正常吗？（有自动测试就让 AI 先跑一遍）
[ ] 它说明白了吗？——AI 是否告诉你改了哪些文件、怎么跑、出问题怎么退。
[ ] 存档了吗？——这一版已经提交过一次，改坏了能退回去。

这张清单不需要你会写代码——每一行都是"用的人"才验得出来的事。正因如此，验收这个岗位天然属于你。

三句「万能验收话术」——不确定怎么验收时直接照用

对任何成品："把它当作要交给真实用户的正式功能，按『功能对不对 →
边界试没试 → 会不会弄坏旧的』三点检查一遍给我。"
对任何改动："先列出你改动了哪些文件、各自为什么；再说明你怎么验证
这次没改坏别的。"
对任何方案："用大白话给我讲这个方案，假设我听不懂术语；再告诉我它
的缺点和最坏情况。"

这三句把"测试＋资深同事"平时会问的问题，浓缩成了几句你随时能说的中文。不知道从哪验收时，挑一句丢给 AI，它会把问题替你想全。

一个心态：把「出问题」当成必然会发生的事

慌乱时人最容易乱点乱试，反而更糟。让 AI 好像把项目搞坏了的时候，按顺序做三个动作，每一步都很便宜：① 停手——立刻别再让它继续改，也别手动删改任何文件；② 看存档——问它"最近几次提交记录是什么"，回到"最后一次是好的"那一次；③ 复述问题——把"出了什么现象、期望是什么、哪一步开始的"发给它，让它先说清原因再动手修，而不是"试着改改看"。

救火能力＝先有存档＋会讲问题＋让 AI 先诊断后动手。把"出问题"当成必然会发生、且早发生比晚发生好的事来准备，你反而更敢让 AI 干活。

13八个常见误解

这八条都是新手真会想、也真会因此吃亏的。每条都先说"错在哪"，再说"它对的那一半是什么"——因为能流传开的误解，通常都有一半是真的。

14新手最容易踩的坑，与出事后先做的三个动作

七个最容易翻车的场景，每个都有防坑动作

遇到「AI 好像把项目搞坏了」：先做这三个动作，别慌

15公司怎么循环这套流程：敏捷、Sprint 与瀑布

七道关不是走一遍就完事，而是像心跳一样循环。公司怎么循环，直接决定你该用什么节奏做自己的东西。

敏捷与 Scrum：把时间切成一段一段

公司不会把功能憋一年才上线，而是一小块一小块、隔一两周就发一版。这个节奏在行业里叫敏捷（Agile）；最常见的套路是 Scrum——按《Scrum Guide》（2020 年版）的原话：

• 把时间切成固定长度的冲刺（Sprint），每个冲刺不超过一个月；
• 冲刺开始时开冲刺计划会，从需求清单里挑这一轮要做的活；
• 每天开一个不超过 15 分钟的站会：各说三句——昨天做了什么、今天做什么、卡在哪；
• 冲刺结束开演示会给需求方看成果，再开复盘会检讨流程哪里能改。

对你一个人的意义很实在：把"我要一口气做完一个大东西"改成"每个周末交付一小块能用的"。这一小块交付单元行话叫"一次迭代"或"最小可验证的一步"。你每次只让 AI 改一小块、立刻点验、立刻发布，东西就永远处在"能用的最新版"，翻车半径很小。

为什么是敏捷，而不是瀑布

老派的做法叫瀑布（Waterfall）：需求→设计→开发→测试→上线，像瀑布一样一层层流下去，绝不回头。

你以后听人说"我们走敏捷／跑 Sprint／两周一个迭代"，说的就是这套"小步快跑"的打法。一个人＋AI 时，它几乎是唯一合理的选择——因为你最大的资产不是钱，是可以快速试错、快速回头的能力。你可以仿照公司的 Sprint 给自己定一个"个人版"，直接抄下来贴进项目章程文件：

# 我的个人 Sprint（贴在 CLAUDE.md 或项目说明里）
- 一周 = 一个 Sprint：只挑 1 个"这个周末必须能用"的小目标。
- 每次动手前：让 AI 先列"改动清单"→ 我确认 → 开工。
- 每周五：验收本周成果，没做完的不要硬塞，顺延到下周并重排优先级。
- 每月一次"复盘"：问 AI "这项目哪里最容易出问题 / 我哪里最浪费"，
  把答案写回规则文件。

16黑话、交付物与易混词对照表

这一节是留给"回来查"的。先说个重要的心态：黑话不是用来炫的，是"压缩上下文"的工具。它不是什么高深知识，多数只是一个长句的缩写；它是什么？是行业为了省时间约定的暗号，一个词背后是一个大家都默认的场景。听到不懂的词，最省事的动作永远是问 AI："这个词用大白话解释＋它是哪个岗位说的＋什么时候用＋给个例子。"

A · 界面与前端圈

B · 测试、发布与运维圈

C · 协作、版本与开会圈

D · 交付物词典：每个岗位交出来的东西叫什么

软件圈还爱用"产出物"的名字当黑话。你验收 AI 时，点名的就是这些词。记住一条规则：先要"便宜的产出"（文字、清单），确认了再要"贵的产出"（代码、成品）。

E · 最容易「听岔」的几对词：先分清，少踩坑

F · 版本号与发布状态：读懂「现在卡在哪」

30 秒自测

用大白话解释下面三句，都能说通，说明这些黑话已经"活"在你脑子里了：① "这个需求这版先不做，进需求池。" ② "前端调后端的接口，数据落库了。" ③ "先上灰度，稳了再全量，出事就回滚。"——哪句卡住，回到对应分组再看一眼即可。

17四周练习路线：把地图变成手感

别想着读完就会。按下面路线每周做一件小事，四周后你就有了自己的第一套"虚拟团队"。每一步都只依赖前一站的成果。

如果今天就想开个头：三个五分钟的事

它们加起来等于"今天你已经当了一次产品经理"：① 打开任意聊天 AI，复制 09 第 1 关那段口令，输入你此刻真实想要的一个小东西，看它怎么追问你；② 把它问出的前 3 个问题抄下来，想想"如果我不回答就直接开工，会做成什么样"；③ 顺手把 12 的验收清单复制进你的备忘录。

四周路线

18常见问题

98参考来源与证据边界

本文的关键事实都能追到下面这几份来源。我把"哪句来自哪里"写清楚，方便你核对，也方便你知道我没读什么。

证据边界与时效

• 哪些是事实，哪些是"通行说法"。岗位职责分工（产品／设计／研发／测试／运维／架构）、七道关的顺序、黑话含义属于长期稳定的行业常识，由百科级与方法说明书级来源支撑。而"AI 让岗位内容变成什么样"（写代码占比下降、判断与验收占比上升、角色变成编排者）依据的是 2025 年以来的研究综述与行业文章，属于当时的主流叙事，会随工具演进——本文一律标明"行业通行说法"，不含"必然如此"的断言。
• 一处自我更正。本文旧版曾把"局部连贯、全局失序"这个提法归给上面那篇 arXiv 论文。核对论文当前版本（v3）的摘要后，里面并没有这个提法，论文的原始题目也从早期的"Vibe Coding for UX Design"改成了现在的《Vibe Coding in Product Teams》。因此本文不再把该说法挂在这篇论文名下，只把它当作行业观察转述。
• 没有做的事。我没有核对任何具体 AI 工具的默认权限与沙箱行为，没有比较各家的多智能体实现差异，也没有量化"一人＋AI 与传统团队"的成本。凡涉及某个产品的具体设置，请以你手上那个版本为准。
• 时效。工作方式与工具名在快速变化，所以本文的 learn:shelf-life 标为 evolving：地图稳定，地图上标注的"当下战况"需要定期核对。

99一句话总结

现在就做的第一件事

合上文章前，把下面这句存进你的剪贴板——它是你"虚拟团队"的第一位员工开工令：

请你先当一位资深产品经理，只提问、不写代码：我要做【你的小想法】，
请一次一个问题，把会影响做法的关键点问清楚；我答完后，把结论整理成
一页需求（含"第一版范围"和"明确不做什么"），再等我下一步指令。

等它问完、你把需求敲定，再回到 10，按"设计 → 架构 → 工程 → 测试 → 发布"一节一节往下喊角色。记住这三句话：先当产品经理问清楚，再当工程师动手——公司里最贵的工序是"想清楚"，而在 AI 时代它从别人手里交到了你手里；流程是制度，不是摆设——七道关每一关都在省时间，跳关省下的几分钟翻车时会以几小时收回来；你验需求，AI 写代码；你定边界，AI 守边界——守住"删改前先问、出事先回退、权限只给项目"三条底线，你的 AI 团队就既快又稳。