不是能调用 LLM，能调用工具就是 AI Agent，也可能仅仅是个自动化 workflow。
AI Agent，自主性才是重点。

必要性还是靠人类，实现性就交给 AI 吧

Claude code的skills与Manus AI的Packages & APIs有些异曲同工，都是为了解决上下文过载和提升复杂任务能力，不同之处在于前者是“提示语封装”，后者是“代码库封装”。

AI产品经理，如何写PRD？

一、原型与交互体验
原型：从Figma转为Bolt.new或v0.dev
交互体验：包括用户输入意图、系统预期行为等

二、核心认知架构
结合CoT（思维链）设计系统提示词模版，切勿复杂架构，ReAct或者Plan-and-Execute能满足大部分需求

三、上下文工程与数据流
上下文来源：包括动态（历史会话）、静态（向量数据库的文档）等
上下文策略：包括分层卸载、信息压缩等

四、工具与行动层
MCP的定义、参数及权限管理

五、评估与测试标准
建立典型用户Query的测试集，形成评估集，跟踪准确性、拒绝率、工具调用成功率、可监测日志等指标

一些大厂的人连 ReAct 基本模式都没搞明白，就开始拽 mcp 这些名称，我也是服了

最近几件重要事情：
1、系统性学习了 AI Agent 设计模式
2、了解前沿的 AI Agent 能力，无论是 claude 还是 Manus
3、独立部署了 E2B 虚拟化，让 SMB 有真正意义的数字员工
4、完成 AI Agent 技术架构升级，无论是应用层、引擎、还是 AI Agent 执行器，兼容 n8n、dify、iframe、API、cluade Agent sdk、openai Agent sdk 等

我发现正在构建的 AI 生产关系平台，供给侧大部分未必是开发者，而是从业多年行业经验的知识工作者，他们靠 wiki 的方式完善 AI Agent 的 skills，从而获得等比例收入。
加油～ My project.

每位 AI 产品经理都有深入理解 context 的写、选、压、隔。

分享我的 vibe coding：

1/ 有个最高指示文档 standards.md，分别指挥 claude.md 和 agent.md 分工角色
2/ cc 是构建者，xcode 是审查者，它们之间在.task 通信
3/ 每个目录有 context.MD, 目录代码变更则自动更新
4/ cluade.md 引用 context.MD，保持 claude.md 精小
5/ docs 目录存放每日需求文档，运行 make.sh 生成今日 prompt 并启动 cc
6/ 管理.task 目录包括 ready/feedback/done/review，存放不同阶段的交互 md 文档
7/ 除了.task 通信，git commit 也是构建者与审查者通信信息，但是 git push 权限在我这里
8/ 审查者实时监听.task/ready 目录文件，有新增则自动审查，决定是 feedback 还是 done

对了，以上在 linux 云主机运行。

关于 tailwindCSS，讲再多不如行动一次