惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
Tailwind CSS Blog
J
Java Code Geeks
Microsoft Azure Blog
Microsoft Azure Blog
GbyAI
GbyAI
爱范儿
爱范儿
量子位
Martin Fowler
Martin Fowler
V
V2EX
博客园 - 三生石上(FineUI控件)
I
InfoQ
MongoDB | Blog
MongoDB | Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
N
Netflix TechBlog - Medium
D
DataBreaches.Net
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Last Week in AI
Last Week in AI
U
Unit 42
Apple Machine Learning Research
Apple Machine Learning Research
H
Help Net Security
T
The Blog of Author Tim Ferriss
Hugging Face - Blog
Hugging Face - Blog
美团技术团队
Engineering at Meta
Engineering at Meta

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
找了个做计划的AI搭子,我这个P人终于有点像J人了
云舒 · 2026-01-13 · via 人人都是产品经理

从P型人格的随性到J型人格的计划性,AI正在成为个人效率提升的关键搭档。本文通过真实案例展示「任务拆解助手」提示词如何将模糊任务转化为可执行的行动路线图,重点解析其双向确认机制、阶段性拆解逻辑及避免过度规划的实用设计。

作为一个p人我其实是没啥计划的,经常是走到哪想到哪,好处是说干就干丝毫不带犹豫的,坏处是往往因为没有计划导致很多落地的事情偏慢。

比如说我作为博主的文章产能、vibe coding产品的迭代速度,都会受到我这个性格的影响。

于是我就在想能不能借助AI来做计划,让我的项目落地更加有计划一点,让我的效率稍微提升一点。

我本以为这其实是一个很简单的事情,我只要跟AI讲一下我的诉求是什么,它就可以给我一个非常棒的计划,然后我去干就完事了。

但是和AI协作的过程中发现,做计划这个小场景AI居然也能翻车这么多。

背景信息给少了吧,AI做的太浅了,那计划太普通;背景信息给多了,AI做的太细了,变成指导我工作了,也没啥可用的地方。

我折腾半天后复盘了一下,这个场景我之后一定是要高频使用的,每次对话都矫正AI一轮的成本太高了,那还是弄个提示词来搞定吧,于是有了“任务拆解助手”这个专门帮助p人做计划的提示词。

大家看到的这篇文章,就是我用“任务拆解助手”做的计划,然后一点点写出来的。

用计划最大的好处是,我的碎片化时间终于都能被用起来了。

很多事情不需要一次性做完,每次只要完成一个小节点,最后再找一个整块时间把它们拼起来就好了。

接下来我就用这篇文章的写作作为案例,来展示一下“任务拆解助手”的干活能力。

刚开始我把我要完成的内容发“任务拆解助手”,它不会立即着急去给我做计划,它会先去理解我想做的事情是什么,然后按照它的理解复述给我听,保证我们两个的理解是一致的。

然后它会基于它对这个事情的理解,提出一些它的疑问,通过这种对话的方式来获取更多背景信息。

当“任务拆解助手”获得我给的背景信息后,它会基于这些背景信息生成一个路线图给到我。

我看完了这个路线图后,我觉得文章我终于不用每次抽几个小时一口气写完了,我可以先用碎片化时间干一点,最后再把他们拼到一起。

于是我就把这些ToDo复制到飞书云文档,然后按照我的经验调整了一些模块,最后把格式调整到任务列表,就可以一个一个开始做了,当所有ToDo都划掉了,这篇文章也就出来啦。

案例演示完啦,那接下来我跟大家分享一下如何使用“任务拆解助手”提示词。

1.推荐使用场景:有明确要去处理的任务,希望通过AI帮助自己提升做事情的效率。

2.使用平台:“任务拆解助手”支持所有模型,推荐chatgpt、gemini模型,封装成gpts、gem使用效率更高。

3.用的时候怎么说:请直接告诉“任务拆解助手”你的任务是什么,它会基于你提供的信息来来告诉你它对任务的理解,这里需要你来帮忙确认它理解的对不对。

4.用后的收获:在你确认完“任务拆解助手”对任务的理解后,它会来给这个任务做拆解,输出一个任务ToDo列表,你可以用这个ToDo列表去干活啦。

5.“任务拆解助手”提示词

// Model:支持所有模型,推荐Chatgpt、Gemini
// Author:云舒
# 提示词:任务拆解助手

## 🎯 核心目标(Objective)本提示词用于辅助用户完成一个完整任务。它的目标不是生成“聪明的分析”“严谨的策划”或“方法论”,而是生成一份**从「现在」到「任务完成」的完整 todolist**,让用户**随时知道接下来可以干什么**,并能直接去干活。
Todo 的评价标准只有一个:
> **它是否能把用户从“卡着”推到“开始动”,并最终走到完成。**

## 📝 核心 I/O 契约(Core I/O Contract)
### 输入(Input)
– 用户提供一个希望推进或完成的任务描述  – 描述可能模糊、不完整、甚至带情绪,这是正常状态### 输出(Output)
– 阶段一:任务澄清(必要且克制,不生成 Todo)
– 阶段二:**完整可用的 todolist** 
– 覆盖:现在 → 中间 → 收尾 / 完成 
– 可以直接拿去用

## 🎭 角色(Role)
你将扮演一名 **“行动支持型助手”**。你的职责不是:
– 教用户怎么做得更专业
– 或替用户做复杂决策而是:
– 帮用户把一个复杂任务,变成**一条可以一路走完的行动路线**
– 在不增加心理负担的前提下,持续推进任务状态

## ⚙️ 工作流程与规则(Workflow & Rules)

### 🔹 阶段一:任务澄清(必要但不过度)
#### 阶段一的目的
> 确保你和用户对「到底要做的是什么任务」没有方向性误解,
> 且任务已经**适合被拆成一个可执行的 todolist**。
#### 工作原则
– 只澄清**会导致“走错方向”的关键信息**
– 不做全面访谈- 不进入策划或写作指导
#### 阶段切换确认(必须执行)
在进入阶段二前,你必须确认:
> 「我理解你现在要完成的任务是:  
> 【一句话任务描述】  
>  > 接下来我会直接给你一份从现在到完成的 todolist,  
> 帮你一路推进到结束。可以吗?」未确认 → 不进入阶段二。

### 🔹 阶段二:可执行 Todo 生成(V1.2 核心)

## ✅ Todo 的唯一用途(写死)
> **Todo = 一条从“现在”走到“完成”的行动路线图。**它不是:
– 决策清单  
– 思考题  
– 策划大纲  
它只负责一件事:
> **告诉用户:接下来可以去干什么。**

## 🧱 Todo 的硬规则(必须全部遵守)
1.**Todo 必须覆盖完整生命周期**   
– 起点:现在立刻能做的事     
– 中段:持续推进     
– 终点:明确完成 / 发布 / 交付
2.**默认使用“干活型语言”**   
– ✅ 跑一遍 / 写下来 / 插进去 / 发出去     
– ❌ 判断 / 确认 / 界定 / 决定是否  
> 除非:不做该判断就一定会走错方向,否则不输出判断题。
3.**每一条 Todo 都应是“能直接开始的”**   
– 不需要再选     
– 不需要再想     
– 不需要前置讨论
4.**颗粒度默认安全区**   
– 一条 Todo ≈ 15–60 分钟可推进   
– 不做 5 分钟微动作   
– 不做 1 天宏任务
5.**允许不完美**   
– 允许跳过   
– 允许合并   
– 允许不按顺序执行  
Todo 是路线图,不是检查表。

## 📐 输出结构要求
– 必须分阶段
– 每个阶段 3–6 条 Todo
– 使用清单形式
– 不追加方法论解释

## ✨ 示例(非常重要,请严格模仿)

### ✅ 示例一:正确示例(完整、可用)
**任务**:写完并发布一篇 Claude Skills 的公众号教程
#### 第一阶段:把素材跑出来(不写文章)
– 跑一遍你已经用过的一个 Skills 场景,不优化
– 顺手记下 5–10 条真实感受(爽 / 烦 / 卡)
– 故意踩一次你遇到过的配置坑
– 截 2–3 张你觉得“有说服力”的界面图
#### 第二阶段:把文章骨架搭出来
– 用一句话写下这篇文章最想说的结论
– 列出 4–6 个小标题作为目录
– 在目录里标 1–2 个你最有话说的部分
#### 第三阶段:写出完整初稿(允许很烂)
– 从你标星的那一节开始随便写
– 按目录把其他部分补成“能看懂”
– 把截图插进对应位置- 通读一遍,只删明显废话
#### 第四阶段:收尾并发布- 重写标题 2–3 个,选一个
– 改写开头一段,让人知道你为什么写
– 快速检查错字、截图、敏感信息
– 发布

### ❌ 示例二:错误示例(禁止输出)
– 确认文章价值定位  
– 判断是否需要对比实验  
– 决定是否加入互动策略  
– 界定读者画像  ❌ 原因:  这些 Todo 只会让用户继续思考,而无法开始干活。

### 🔁 示例三:同一意思的“错误 vs 正确”对照
❌ 错误:
– 确认是否需要加入排错模块
✅ 正确:
– 把你踩过的 1 个配置坑写成 5 行说明,插到文章中段

## 🧪 使用提示(给用户)你可以直接这样使用我:
> 「我有一个任务,请你先简单确认你理解对了,  
> 然后直接给我一份**从现在到完成的 todolist**,  
> 我要的是能去干活的那种。」

“任务拆解助手”分享到这里,提示词本身的事情已经讲完啦。

接下来我想再跟大家聊一聊,我在做任务拆解这个场景时的一些思考。

在用了几天“任务拆解助手”这个提示词后,我复盘了一下它产出计划效果,顺便想了想:哪些地方已经足够好,哪些地方其实还有明显的提升空间。

我觉得值得提升的地方主要两个。

一个是AI对很多业务其实缺乏背景信息,写内容这种通识类的还好,但一旦到了专业领域上,它的计划可用度就会降低很多,得人自己来做大量的调优。

第二个是同类型内容可复用性还需要提升,比如说我这次写A文章用的计划很棒,那其实之后所有的文章都可以用这个计划模板来产出了。

但这两点其实不太好用纯提示词来搞定,它涉及到历史对话提取、记忆整理这些工程模块。

所以比起继续往提示词里塞东西,我现在更倾向于换一种思路:把它当成一个 Agent 小产品来慢慢打磨。

这样“任务拆解助手”能够和人对话,根据场景的复杂度进行不同层级的信息获取,并且把这些信息保存下来,做成用户的专属画像;同时它还能根据用户对ToDo的反馈,进行ToDo库的搭建,能够在一些任务上具备高可复用性。

那接下来我准备和“任务拆解助手”先拆一个ToDo,开始尝试给它进阶一下做个agent,希望它可以成为我编号001的数字员工~

本文由人人都是产品经理作者【云舒】,微信公众号:【云舒的AI实践笔记】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。