即刻App年轻人的同好社区
下载
PRD 文件说明要干什么
TECH 文件做技术/架构分析
STORY 是如何拆分
SLICE 做竖切，做保障
TASK 文件是任务拆分
最后由 PROJ 文件进行整体串联和协调
文档都搞定了之后，进入开发阶段
agent proj 会以PROJ文件为指导，开始协调 agent dev 开发， agent tech 做review
出了问题找 agent tech 改文档，然后 proj 继续推进开发
这样就形成了 proj 做调度，dev 开发 tech review 的整体流程
因为 proj 做调度，好处是，每次他生成的指令，都会比较完备，比如查看什么文档的什么位置
如果是我，就不会写的这么详细，这样对 dev 的驱动，他比我做得好
我被迫不关注过程，不看vscode，只跟 proj 确认进度和完成情况
github.com
TECH 文件做技术/架构分析
STORY 是如何拆分
SLICE 做竖切，做保障
TASK 文件是任务拆分
最后由 PROJ 文件进行整体串联和协调
文档都搞定了之后，进入开发阶段
agent proj 会以PROJ文件为指导，开始协调 agent dev 开发， agent tech 做review
出了问题找 agent tech 改文档，然后 proj 继续推进开发
这样就形成了 proj 做调度，dev 开发 tech review 的整体流程
因为 proj 做调度，好处是，每次他生成的指令，都会比较完备，比如查看什么文档的什么位置
如果是我，就不会写的这么详细，这样对 dev 的驱动，他比我做得好
我被迫不关注过程，不看vscode，只跟 proj 确认进度和完成情况
github.com
0 00
既然已经给 AI 设定了人格，那就让他们团队开发起来
左上：架构师，负责架构等设计
左下：开发，主要负责后端任务
右下：开发，主要负责前端任务
右上：项目经理，负责整体的协调沟通，并生成给另外三个窗口的完整指令，驱动他们干活。同时安排任务顺序，保障左下和右下的开发可以并行开发不冲突
昨天按照这个方式开发，最大改变是心智的改变
我现在让 proj 作为主控，生成给其他的人格窗口的指令
因为同步进行的原因，我已经很难跟得上他们的节奏了
所以我“被迫”让自己改为关注 proj 的进度文档，以及最终交付物，过程“彻底”忽略
这和管理人的团队，已经很接近了
左上：架构师，负责架构等设计
左下：开发，主要负责后端任务
右下：开发，主要负责前端任务
右上：项目经理，负责整体的协调沟通，并生成给另外三个窗口的完整指令，驱动他们干活。同时安排任务顺序，保障左下和右下的开发可以并行开发不冲突
昨天按照这个方式开发，最大改变是心智的改变
我现在让 proj 作为主控，生成给其他的人格窗口的指令
因为同步进行的原因，我已经很难跟得上他们的节奏了
所以我“被迫”让自己改为关注 proj 的进度文档，以及最终交付物，过程“彻底”忽略
这和管理人的团队，已经很接近了
0 00
🧠
如果想要让开发小队转起来
在文档阶段
1. 要有明确的验收标准
2. 要有明确的完成标准
否则，很难出现一个协调者。 这个协调者需要知道上面的内容，才能分别驱动不同的身份去干不同的事情
如果有一个工作台，这个协调者，驱动自己/其他的 Agent 去对当前正在进行的目标进行结果验收，不管是驱动干活的文档，还是干活的 dev
那会进一步的自动化起来
如果想要让开发小队转起来
在文档阶段
1. 要有明确的验收标准
2. 要有明确的完成标准
否则，很难出现一个协调者。 这个协调者需要知道上面的内容，才能分别驱动不同的身份去干不同的事情
如果有一个工作台，这个协调者，驱动自己/其他的 Agent 去对当前正在进行的目标进行结果验收，不管是驱动干活的文档，还是干活的 dev
那会进一步的自动化起来
1 00
今天在路上突然想明白一件挺“恐怖”的事。
我最近在公司管的事情越来越多，一度认真想过：
要不要再招一个人，把机器人项目代码完整接过去？
但我马上又问了自己一个问题：那我到底招他来干嘛？
定方向、定需求、做 Review —— 这些最后还得我来拍板。
那这个人其实并没有真正“接走”任何一块脑力。我只是要一双手而已
而这些事，我现在完全可以交给自己的开发小队，
甚至，在我每天和 Claude Code 一起工作的过程中，我已经不是具体实施的主体了，我现在更多的是进行协调开发小队和进行产出 Review。
这个感觉以前只是隐约有，
但当我今天站在“要不要再招一个人”的路口时，突然变得异常清晰：
👉 招聘的形式，正在被 AI 彻底改写
👉 团队的成员，自然有和赛博人的边界，已经开始模糊
这可能是我这几年，对组织形态变化最强烈的一次体感。
我最近在公司管的事情越来越多，一度认真想过：
要不要再招一个人，把机器人项目代码完整接过去？
但我马上又问了自己一个问题：那我到底招他来干嘛？
定方向、定需求、做 Review —— 这些最后还得我来拍板。
那这个人其实并没有真正“接走”任何一块脑力。我只是要一双手而已
而这些事，我现在完全可以交给自己的开发小队，
甚至，在我每天和 Claude Code 一起工作的过程中，我已经不是具体实施的主体了，我现在更多的是进行协调开发小队和进行产出 Review。
这个感觉以前只是隐约有，
但当我今天站在“要不要再招一个人”的路口时，突然变得异常清晰：
👉 招聘的形式，正在被 AI 彻底改写
👉 团队的成员，自然有和赛博人的边界，已经开始模糊
这可能是我这几年，对组织形态变化最强烈的一次体感。
0 00
用一张双轴图，把工程投入和业务价值对齐
横轴：次抛 → 生长 → 产品
- 次抛：快速拿结果（验证价值）
- 生长：开始复用、开始沉淀（可扩展）
- 产品：可持续交付（配置化、可运营、可被多人使用）
纵轴：单次成品 → 自动化 → 7×24
- 单次成品：人工跑一次，有结果就行，错了再跑
- 自动化：定时/触发跑起来，有基本校验、产物留存
- 7×24：无人值守稳定运行，能重试/降级/告警/追溯
三个关键落点：在哪个点就该投入什么级别的“架构”
① 左下（次抛 × 单次成品）
适合：一次性分析、快速验证、临时脚本、PoC
架构重点：别过度设计，但一定要有最小契约（输入/输出字段别乱、关键假设写清楚）。
✅ 允许粗糙实现；❌ 不允许结果不可解释。
② 中间（生长 × 自动化）
适合：每周都要用的报表/分析、周期性同步、可复制的运营动作
架构重点：开始工程化：schema 固化、校验、幂等、重跑、日志、产物留存、最小监控。
✅ 能稳定重复产出；❌ 不能靠人盯着跑。
③ 右上（产品 × 7×24）
适合：规模化系统（群发/客服/风控/运营中台/数据管道）
架构重点：边界与配置化 + 可观测性 + 失败策略：权限审计、告警、降级兜底、版本演进、回滚、SLA。
✅ 多人可用、可运营、可持续迭代；❌ 不能“只有我能改”。
怎么判断业务里一个东西该落在哪？
Q1 - 频率：一周用几次？（高频 → 往上：自动化）
Q2 - 风险：错一次代价多大？（高风险 → 往上：7×24）
Q3 - 复用：会不会扩到更多场景/团队？（高复用 → 往右：产品化）
频率决定自动化，复用决定产品化，风险决定7×24。
每次升级只选一个方向：要么“往上做稳定”，要么“往右做复用”，不要一起做
不再纠结“要不要做架构”，而是先回答：它现在在哪个坐标？下一步应该往哪迁移？
横轴：次抛 → 生长 → 产品
- 次抛：快速拿结果（验证价值）
- 生长：开始复用、开始沉淀（可扩展）
- 产品：可持续交付（配置化、可运营、可被多人使用）
纵轴：单次成品 → 自动化 → 7×24
- 单次成品：人工跑一次，有结果就行，错了再跑
- 自动化：定时/触发跑起来，有基本校验、产物留存
- 7×24：无人值守稳定运行，能重试/降级/告警/追溯
三个关键落点：在哪个点就该投入什么级别的“架构”
① 左下（次抛 × 单次成品）
适合：一次性分析、快速验证、临时脚本、PoC
架构重点：别过度设计，但一定要有最小契约（输入/输出字段别乱、关键假设写清楚）。
✅ 允许粗糙实现；❌ 不允许结果不可解释。
② 中间（生长 × 自动化）
适合：每周都要用的报表/分析、周期性同步、可复制的运营动作
架构重点：开始工程化：schema 固化、校验、幂等、重跑、日志、产物留存、最小监控。
✅ 能稳定重复产出；❌ 不能靠人盯着跑。
③ 右上（产品 × 7×24）
适合：规模化系统（群发/客服/风控/运营中台/数据管道）
架构重点：边界与配置化 + 可观测性 + 失败策略：权限审计、告警、降级兜底、版本演进、回滚、SLA。
✅ 多人可用、可运营、可持续迭代；❌ 不能“只有我能改”。
怎么判断业务里一个东西该落在哪？
Q1 - 频率：一周用几次？（高频 → 往上：自动化）
Q2 - 风险：错一次代价多大？（高风险 → 往上：7×24）
Q3 - 复用：会不会扩到更多场景/团队？（高复用 → 往右：产品化）
频率决定自动化，复用决定产品化，风险决定7×24。
每次升级只选一个方向：要么“往上做稳定”，要么“往右做复用”，不要一起做
不再纠结“要不要做架构”，而是先回答：它现在在哪个坐标？下一步应该往哪迁移？
0 00
大家好，我是大铭，一个 Agent 开发者
最近在做“妈妈智能体助手”的时候，有一种强烈的感觉：AI 软件不能像之前那样使用了。 时代变了，产品要变，但具体怎么变，却一时说不清楚
我们正站在一个巨大的变革路口，却还在用旧地图找新大陆
市面上各种所谓的 AI 产品，功能眼花缭乱，但用起来总有点“不对劲”，感觉就像是“旧瓶装新酒”
我们很多人，包括产品设计者，都还在不自觉地沿用传统互联网产品的思路来对待 AI，这极大地束缚了 AI 真正的潜力。问题的根源在于，我们对“价值交付”的理解，还停留在上一个时代
核心变革：从“授人以渔”到“授人以鱼”
那句点醒我的话，就是 **“授人以鱼，而非授人以渔”**
这里的“鱼”，就是能直接吃的鱼。意思是，既然我们能直接交付成果，就不要只交付方法。
旧范式：“授人以渔”的无奈
以前的互联网产品，本质上都是在“授人以渔”。为什么？因为技术没办法对用户有足够深入的了解，无法洞察你真正的意图，所以它只能给你一套方法论，让你自己去做。
它的集中体现，就是给你一个又一个的**看板、客户标签、分析工具**等等。这些都属于传统互联网产品的延展。它给你鱼竿、鱼饵和一张模糊的地图，然后让你自己下海去捕鱼，至于能不能捕到、捕多少，那是你自己的事。
新范式：“授人以鱼”的能力
但现在到了 AI 时代，一切都变了。AI 能做很多与 **意图（Intent）** 相关的事，能无限贴近用户的真实需求。
所以，我们完全没必要再给用户一套复杂的方法论。AI 可以直接替用户把每个人的情况、行为都服务好、筛选好。作为用户，你只需要拿到那个最终的结果就行了，根本没必要再去学习那些复杂的捕鱼方法。
这在我做“妈妈智能体助手”时感觉尤其深刻。
一个妈妈要的不是一个能搜索附近活动的工具（渔具），她真正要的是一个能直接告诉她“根据天气和宝宝的午睡习惯，周末下午3点去XX公园的亲子绘本角是最佳选择，门票已为你预订”的贴心助手（鱼）。
到这个时候，就会形成这样的情况：**我直接交付的是一个结果，而不是一个过程，也不是方法论**
新范式下的两个角色：“AI实习生”与“AI顾问”
基于“交付结果”这个核心，AI 在我们工作中的角色也彻底变了，它不再是冷冰冰的工具，而是两个极具价值的“角色”。
给老板的“AI实习生”
对于老板来说，我们要提供一个“AI实习生”。
具体来说，比如一个卖饮料的企业，以前老板想决定接下来主打什么口味，他得亲自去统计销售情况、查看各种报表订单。但现在，这些都可以交给 AI 去分析。这个“AI实习生”会直接告诉他结论：
老板，数据分析显示，最近四周草莓味饮料销量越来越多，建议主攻草莓味或加大投放；而巧克力味连续四周持续低迷，可以考虑停产了。
老板要的就是这个直接的结果，而不是一堆让他自己去看、效率极低的工具和报表。更强大的是，如果企业有**几十个、上百个、甚至上千个门店**，这个“实习生”还能为每个门店提供个性化的分析。这时，它就相当于雇佣了一个水平相当不错的员工。
给员工的“AI顾问”
对于员工来说，AI 则应该是一个“金牌顾问”。以前我们讲加速，是效率的加速；**现在应该是认知的加速**
“认知加速”的意思是，要把业内较高的认知快速落地到企业内，让高水平员工的认知能快速复制给其他人。员工没必要凡事都自己从头摸索、再学习一遍。因为 AI 可以学习企业内、乃至全社会优秀同行的做法
比如，当客户问到一个复杂的内部知识或服务问题时，员工没必要再去费力查资料。学习过相关内容的“AI顾问”可以直接把最优答案和话术提醒给他，甚至在员工授权的情况下，直接替他完成某些沟通和服务。
我的两个“暴论”：AI 时代的产品机会
基于以上的思考，我会有自己的一个悖论：**这种直接交付结果的机会，其实非常非常多，多到做不完**
在这种情况下，我自己对于 AI 时代的产品有两个“暴论”：
暴论一：产品形态和交互与主流产品类似，那大概率是做错了
如果你的 AI 产品看起来、用起来和现在的很多软件都差不多，那它很可能只是一个互联网产品的延展，而不是原生于 AI 时代的新物种。
你想，如果体验上差不多一样，那它大概率还是在交付**“过程”和“方法”** 。同时，既然已经有类似的功能了，别人干嘛要放弃已经成熟的产品来用你的呢？
暴论二：真正的蓝海，在于“只有需求，没有供给”的细分场景
我们一定要去发现新的场景和机会，而这些机会一定是**交付结果，而不是交付过程**——也就是交付能吃的鱼，而不是打鱼的工具。
在这方面，一定有大量的机会。因为我们在日常无论是 B 端工作还是 C 端工作，都有海量的工作需要解决，这些工作**非常细分、非常个性化**。对于这些问题，我们需要去解决，其范围非常广，可能永远也挖掘不完。
并且，因为场景会变得极其丰富，细分赛道非常多，我们会发现大量的场景其实是 **“只有需求，没有供给”** 。那么理论上，在这些场景里，你只要把能直接解决问题的产品做出来，应该是不愁卖的。
AI Native 产品，拥抱“结果主义”
归根结底，AI 时代的产品哲学，是一种“结果主义”。
当然，如果说得更细一点，我们产品开发的过程，是为了达到更好的结果，这些过程（比如数据处理）其实还是为了辅助AI。而方法论，如果你愿意的话，我可以给你，但它不应该再被定义为我绝对的卖点了。这，已经不再是一个传统的服务。
现在，你可以审视一下你自己的工作和产品：**有哪些地方，你还在辛苦地“打渔”，而实际上，本可以由 AI 直接为你“送鱼”？**
想清楚这个问题，可能就是我们抓住 AI 时代机遇的真正开始。
最近在做“妈妈智能体助手”的时候，有一种强烈的感觉：AI 软件不能像之前那样使用了。 时代变了，产品要变，但具体怎么变，却一时说不清楚
我们正站在一个巨大的变革路口，却还在用旧地图找新大陆
市面上各种所谓的 AI 产品，功能眼花缭乱，但用起来总有点“不对劲”，感觉就像是“旧瓶装新酒”
我们很多人，包括产品设计者，都还在不自觉地沿用传统互联网产品的思路来对待 AI，这极大地束缚了 AI 真正的潜力。问题的根源在于，我们对“价值交付”的理解，还停留在上一个时代
核心变革：从“授人以渔”到“授人以鱼”
那句点醒我的话，就是 **“授人以鱼，而非授人以渔”**
这里的“鱼”，就是能直接吃的鱼。意思是，既然我们能直接交付成果，就不要只交付方法。
旧范式：“授人以渔”的无奈
以前的互联网产品，本质上都是在“授人以渔”。为什么？因为技术没办法对用户有足够深入的了解，无法洞察你真正的意图，所以它只能给你一套方法论，让你自己去做。
它的集中体现，就是给你一个又一个的**看板、客户标签、分析工具**等等。这些都属于传统互联网产品的延展。它给你鱼竿、鱼饵和一张模糊的地图，然后让你自己下海去捕鱼，至于能不能捕到、捕多少，那是你自己的事。
新范式：“授人以鱼”的能力
但现在到了 AI 时代，一切都变了。AI 能做很多与 **意图（Intent）** 相关的事，能无限贴近用户的真实需求。
所以，我们完全没必要再给用户一套复杂的方法论。AI 可以直接替用户把每个人的情况、行为都服务好、筛选好。作为用户，你只需要拿到那个最终的结果就行了，根本没必要再去学习那些复杂的捕鱼方法。
这在我做“妈妈智能体助手”时感觉尤其深刻。
一个妈妈要的不是一个能搜索附近活动的工具（渔具），她真正要的是一个能直接告诉她“根据天气和宝宝的午睡习惯，周末下午3点去XX公园的亲子绘本角是最佳选择，门票已为你预订”的贴心助手（鱼）。
到这个时候，就会形成这样的情况：**我直接交付的是一个结果，而不是一个过程，也不是方法论**
新范式下的两个角色：“AI实习生”与“AI顾问”
基于“交付结果”这个核心，AI 在我们工作中的角色也彻底变了，它不再是冷冰冰的工具，而是两个极具价值的“角色”。
给老板的“AI实习生”
对于老板来说，我们要提供一个“AI实习生”。
具体来说，比如一个卖饮料的企业，以前老板想决定接下来主打什么口味，他得亲自去统计销售情况、查看各种报表订单。但现在，这些都可以交给 AI 去分析。这个“AI实习生”会直接告诉他结论：
老板，数据分析显示，最近四周草莓味饮料销量越来越多，建议主攻草莓味或加大投放；而巧克力味连续四周持续低迷，可以考虑停产了。
老板要的就是这个直接的结果，而不是一堆让他自己去看、效率极低的工具和报表。更强大的是，如果企业有**几十个、上百个、甚至上千个门店**，这个“实习生”还能为每个门店提供个性化的分析。这时，它就相当于雇佣了一个水平相当不错的员工。
给员工的“AI顾问”
对于员工来说，AI 则应该是一个“金牌顾问”。以前我们讲加速，是效率的加速；**现在应该是认知的加速**
“认知加速”的意思是，要把业内较高的认知快速落地到企业内，让高水平员工的认知能快速复制给其他人。员工没必要凡事都自己从头摸索、再学习一遍。因为 AI 可以学习企业内、乃至全社会优秀同行的做法
比如，当客户问到一个复杂的内部知识或服务问题时，员工没必要再去费力查资料。学习过相关内容的“AI顾问”可以直接把最优答案和话术提醒给他，甚至在员工授权的情况下，直接替他完成某些沟通和服务。
我的两个“暴论”：AI 时代的产品机会
基于以上的思考，我会有自己的一个悖论：**这种直接交付结果的机会，其实非常非常多，多到做不完**
在这种情况下，我自己对于 AI 时代的产品有两个“暴论”：
暴论一：产品形态和交互与主流产品类似，那大概率是做错了
如果你的 AI 产品看起来、用起来和现在的很多软件都差不多，那它很可能只是一个互联网产品的延展，而不是原生于 AI 时代的新物种。
你想，如果体验上差不多一样，那它大概率还是在交付**“过程”和“方法”** 。同时，既然已经有类似的功能了，别人干嘛要放弃已经成熟的产品来用你的呢？
暴论二：真正的蓝海，在于“只有需求，没有供给”的细分场景
我们一定要去发现新的场景和机会，而这些机会一定是**交付结果，而不是交付过程**——也就是交付能吃的鱼，而不是打鱼的工具。
在这方面，一定有大量的机会。因为我们在日常无论是 B 端工作还是 C 端工作，都有海量的工作需要解决，这些工作**非常细分、非常个性化**。对于这些问题，我们需要去解决，其范围非常广，可能永远也挖掘不完。
并且，因为场景会变得极其丰富，细分赛道非常多，我们会发现大量的场景其实是 **“只有需求，没有供给”** 。那么理论上，在这些场景里，你只要把能直接解决问题的产品做出来，应该是不愁卖的。
AI Native 产品，拥抱“结果主义”
归根结底，AI 时代的产品哲学，是一种“结果主义”。
当然，如果说得更细一点，我们产品开发的过程，是为了达到更好的结果，这些过程（比如数据处理）其实还是为了辅助AI。而方法论，如果你愿意的话，我可以给你，但它不应该再被定义为我绝对的卖点了。这，已经不再是一个传统的服务。
现在，你可以审视一下你自己的工作和产品：**有哪些地方，你还在辛苦地“打渔”，而实际上，本可以由 AI 直接为你“送鱼”？**
想清楚这个问题，可能就是我们抓住 AI 时代机遇的真正开始。
https://mp.weixin.qq.com/s/Wy9Dz4MxmxWrCyuj64U5Dw
1 00
