即刻App年轻人的同好社区
下载
基于 ob 的个人 Ai 工作台做了一个升级，增加文章抓取功能
发送一个文章链接
👇
抓取保存全文在 ob
👇
以完整且独立的原则拆成N张知识卡片
👇
结合 ob 已有的知识库和联网搜索内容，深入分析生成洞见和行动计划
现在快速分拣 AI 可以处理任务和 URL 文章了，逐步再增加新的功能进去
你期待什么自动化 AI 功能呢？
发送一个文章链接
👇
抓取保存全文在 ob
👇
以完整且独立的原则拆成N张知识卡片
👇
结合 ob 已有的知识库和联网搜索内容，深入分析生成洞见和行动计划
现在快速分拣 AI 可以处理任务和 URL 文章了，逐步再增加新的功能进去
你期待什么自动化 AI 功能呢？
0 00
四个窗口并行开发
直接把 GLM Pro Plan 干爆了，429
每小时可以消耗将近 2000w token
项目管理，proj 炮哥，协调并行
架构师，tech 泰哥
负责review 的架构师 ， tech 泰瑞
开发，戴夫 1-n
github.com
直接把 GLM Pro Plan 干爆了，429
每小时可以消耗将近 2000w token
项目管理，proj 炮哥，协调并行
架构师，tech 泰哥
负责review 的架构师 ， tech 泰瑞
开发，戴夫 1-n
github.com
0 00
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