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

推荐订阅源

T
Tailwind CSS Blog
MyScale Blog
MyScale Blog
博客园 - Franky
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
有赞技术团队
有赞技术团队
雷峰网
雷峰网
罗磊的独立博客
小众软件
小众软件
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
V
V2EX
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
The Cloudflare Blog
Hugging Face - Blog
Hugging Face - Blog
博客园 - 【当耐特】
博客园 - 司徒正美
Last Week in AI
Last Week in AI
月光博客
月光博客
阮一峰的网络日志
阮一峰的网络日志
美团技术团队
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
量子位
宝玉的分享
宝玉的分享

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
TCREI框架:提示词应该怎么写
S-饭特稀 · 2026-02-24 · via 人人都是产品经理

在AI工具泛滥的今天,真正决定输出质量的往往是那些被忽视的提示词设计。本文揭秘TCREI框架的实战应用,从角色定义到迭代优化,手把手教你如何通过精准的提示词控制AI输出,避免'AI幻觉'陷阱,让你的需求得到100%满足。

随着AI的发展越来越快,昨天agent, 今天skills,明天不确定又有什么新的热词涌现出来,对我来说日常用的最多的还是聊天形式的AI工具。

当然行业不同,使用目的不同,对于AI的需求也不一样,但不管怎样,如果想要让AI满足你想要的结果,提示词是绕不过去的,尽管线上到处都是各类现成的提示词,但我始终觉得,自己需求只有自己最清楚,硬套其他人提供的提示词,不一定能满足,还是建议大家自己写。

按照TCREI的框架进行书写,其中:

  • T,即Task任务;
  • C,即Context背景(上下文);
  • R,即References 参考资料;
  • E,即Evaluate 评估;
  • I,即Iterate 迭代。

就是在写提示词时要明确告诉AI:你是谁?你需要他做什么?按照什么标准(上下文)进行执行? 执行之后,对执行结果进行评估(避免AI幻觉的出现),直到满足你的要求。

展开来说一下:

  • Task任务, 就是你要告诉AI 你需要它作为什么角色?做什么?
  • Context背景(上下文),就是告诉你做这件事的前因后果,为什么要做?想解决什么问题?
  • References 参考资料,为AI 提供输出内容的参考,以此为限制条件,类似于告诉AI 输出的标准。
  • Evaluate 评估,这个是给AI 分配评审角色,对任务执行结果,进行评估并提供反馈意见,避免AI 幻觉或者一本正经的胡说八道。
  • Iterate 迭代,告诉AI 根据评估意见进行调整,然后再让AI 评审角色进行评审直到没有任务意见。

接下来,我让AI帮忙写一份软件实施方案,以下是我的提示词, 仅供参考。

1. 分析需求,作为软件实施方案评审专家,软件实施方案中的写作目的是什么?你关注的是什么?

2. 需求细化,作为软件实施方案评审专家,软件实施方案中的需求分析和技术指标具体写什么(内容要求)?为什么要写(写作目的)?

任务1:作为软件实施方案撰写专家,参考软件实施方案中需求分析和技术指标的写作目的、内容要求、基于以下技术指标进行2个模块的内容撰写(背景和参考),原则:严格基于技术指标内容,贴合需求分析和技术指标的写作目的和内容要求进行内容的撰写。

任务2:作为软件实施方案评审专家,对软件实施方案撰写专家输出的撰写内容,基于需求分析和技术指标对应的写作目的和内容要求,贴合技术指标进行多轮评审,提供调整意见(评估)。

任务3:作为软件实施方案撰写专家,基于软件实施方案评审专家

提出的调整意见,对撰写内容进行调整,然后提交给软件实施方案评审专家进行评审,直到没有任务调整意见(迭代)。

以上内容,源于谷歌官方《提示词基础》以及个人使用过程中的经验总结。

本文由人人都是产品经理作者【S-饭特稀】,微信公众号:【S-饭特稀】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议