AI 读取文件，到底是在干嘛？只是加载文件内容还是发送请求理解文档内容？

AI 项目，快速选择技术栈、skill、开发经验。这些技术栈

快速生成 ai 配置说明

开发规范

母技能，根据母技能场景化的子技能

AI 创建 skill 以及配置文件的问题

太具体了，针对当前的上下文状态，换个会话可能失效！应该更加通用

agent 遵守指令的命名有待提升

需要用户确认的事情，用户几次对话之后没有管，就被自动确认执行了。commit 操作。

AI-claude-code 经验

当仓库 ignore 文件之后，claude code 也会 ignore。

Deepseek，当长内容进行转化为 md 格式时，一会代码块，一会直接输出，格式混乱。所有 AI 都会这样。为了防止格式混乱，外层不嵌套代码块即可。

将下列内容用 markdown 格式输出，直接输出内容，最外层不要套代码块：

转化格式的任务，不需要深度思考。

HTML 转 md，写一个脚本，然后再让 AI 调整样式（添加代码块code）。

让 ai 把 pdf 转化为 markdown 就是一坨大便

claude code 默认加载的是 User 级别的 memory，不会加载项目级别的 memory

先让 ai 学习开发经验，然后再开发

AI 机制

AI 不会自动更新有关联的内容，你得手动说明。不会主动找任务与当前项目中文件的关联。

Agent 工作流看板。可视化 plan，agent 角色

AI 自进化

用户手动纠正过的行为，就持久化记忆。

多次提问效果显著好于一次指定多个任务

尽可能不要擅自修改 ai 编辑的文档内容，会影响缓存读取

AI 机制

工作流用伪代码来表示，然后将伪代码转化成一个工作树，依次执行。编译器，语法树。

中间的执行过程，全用文字描述即可。

AI 机制

就算是写好了规则，让 AI 一次性执行完，效果也远不如多次交流对话，依次执行的效果，我不知道是不是错觉。只要是长任务就会有偷懒的感觉。

还是说，得用 subAgent 模式

对 AI 不要使用反问句

AI 反思的能力比较弱

AI 机制

讲解的时候，不仅仅是要雪冬，还得要讲懂，不仅仅是输出。向 AI 提问的时候，看懂跟讲懂是两种

AI 维护内容机制

不要专门让 AI 执行某个特殊的需求维护，而是加载的时候顺便维护。

因为单独执行维护这个操作会进行消耗大量的 token，加载内容，而且有效性只有这一个任务需求，读取完了之后维护一下就结束了，后续不能再利用这个加载的内容 token 执行其他任务（一般不会）。太消耗 token 了

正确做法：让 AI 读取文档的时候，顺带执行维护任务，减少专门的维护次数，还能在维护内容的同时，执行相关的任务需求！对照维护清单依次确认

写在 CLAUDE.md 中

AI 记忆机制

整理记忆的时候，把多个项目中的记忆等相关的配置，提取出来，保留一份原始数据，然后再整理一份提炼后的机制。

原始数据很重要，不能轻易删除。

AI经验-积累文档

不让AI一次性重构，而是遇到问题再修复，不一次性修复，调整到这个文件的时候顺手维护。

分散维护代码。

积累的经验应该是通用的，有些是独特的特殊的需求。

积累的经验要分为规范跟要求。

普适的要求，去除场景后的规范。

Vibe Coding为什么非得要让AI自己不停止地写代码？本来就应该需要人来监管，做决策，放弃让AI直接生成产品的尝试！

AI 使用经验

当 AI 生成了内容的时候，通过有上下文的记忆，类似于一个内存中的变量，手动修改这个内容之后，再让 AI 调整格式，它会把旧的内容（缓存变量）直接改过去，他是不知道内容已经被修改过的，除非重新读取。

类似于：

• AI 生成了 content
• 用户手动修改了 content，现在是 content_ 了
• 用户让 AI 调整文档的结构、顺序等
• AI 直接使用了 content 进行调整，不知道现在已经变成了 content_
• 只有让 AI 重新读取，才能行，否则就得自己再改一次（缓冲数据省 token 跟准确性，鱼和熊掌不可兼得）

这个缓冲数据就是类似于变量，直接插入数据，替换数据（我是这么理解的），AI 管理了每次生成的内容，以及内容的坐标。所以尽量避免手动修改内容，否则可能引发缓冲数据过时的问题

上下文非常重要，会影响ai回答。prompt不能随便写，而是要符合语境，符合回答的内容的主题，期望回答的内容的语境。

贴上人物身份，减少你我这种主观内容，减少ai的迎合

讲解skill使用示例的skill

skill 减少分支，减少推理的 token 消耗，先剪枝再探索。

创建标签的 skill 。通过内容进行猜测。只是内容，内容描述。

当需要学习一个东西的时候，给 AI 具体的学习目标，然后让 AI 自己提问，然后整理问题的回答，模拟人学习的过程，然后用户自己吸收整个学习过程就好了，不去自己探索，直接学 AI 已经学过了的，提问的内容。

agent聊天室，持久化存储聊天记录，像聊天一样，互相聊，群聊

ai交互。后端程序员，前端程序员，听从项目经理的规划，然后开发。不清楚的直接问，然后通过项目经理问用户。

直接学习别有优秀的开源项目的项目结构，让 AI 总结开发范式。然后拿来运用。作为开发规范。

提示词很难被复用，但是提示词参考的资料可以经常被复用。没必要花大量时间调提示词，但是可以整理参考资料。因此，搞一个知识库才是最重要的。

AI探索模式，而不是一味地根据经验推理。自主推断，主观能动性，结合经验

刚开始阶段都是先跑起来，然后再优化

3层agent，boss，worker

ai 执行任务前，先询问用户，是否理解正确，任务。想讲解大致的任务完成过程。

整理ai开发中遇到的问题，然后用设计思想，解决问题

prompt-optomizer处理隐私数据，脱敏

字数统计的 skill

语音输入+prompt optimizer

项目经理skill

我是用户，项目经理理解我的需求，转化为专业的描述语言

TODO: 整理所有的项目中的对话记录。导出所有的聊天记录，然后整理过程、经验。

遇到的问题。解决的问题。作为经验。实践过程。

AI开发前端的工作流

生成测试的demo页面，一个组件一个组件的搭建，先当UI设计师，然后才是前端开发工程师

写完了skill要验证，做测试

写skill的时候，变量非常重要，明确哪些是固定的常量，哪些是变量。

找ai问可以利用的经验。与ai交流，总结。

skill 的健壮性。像测试代码一样，测试 skill 的效果

总结个人公司的失败经历，特点

CLAUDE 文件中不存对于每个文件的具体说明，只说明目录，或者固定的、特殊的文件

傻子提问者

针对每一个文档，连续，有上下文。每一章，

一旦有新概念，就提出来，如果已经讲解过了，就认为懂了。

一个写稿人决定是否补充内容。

写一个脚本，自动同步 claude code 的配置

prompt 最好写正向提示词，尽量避免写反向约束

AI执行要有思维链，每一个操作都要有原因。

先尽可能收集已知条件，找问题的切入点，然后分析思路，反问，然后思考解决方法，执行，完成。

开发一个模块，就写一个文档

从多个 skill 中提取用户的习惯。

提问与文档整理分开

原生的用户提问的记录

整理好的开发手册

AI 写代码考虑的各种情况不全面，导致每次写代码正确了一半，还有一部分需要通过测试程序才能知道出现了问题

AI 写代码，不会主动找相关的文件，找上下文，不会主动的看 git 记录，与他人同步进度，同步开发思路。得手动指定，说明。团队写作的原则、处境。

提示词打磨器-多轮对话记录打磨的提示词，对比输出结果

AI 提示词，最好是把所有可能出现的情况都列举出来，而不是让 ai 自己推理，自己猜。这样更加省 token，减少思考时间。

反之，可以通过这样的测试，来判断一个 token 是否足够优秀。就好像 code test 环节中的各种情况的测试，我要一杯咖啡，我要 99 杯咖啡，我要一份蛋炒饭...

claude code 使用问题

在仓库中，忽略了 claude code 的配置文件，会导致多分支下，配置文件混乱

agent选择skill的机制，得多轮选择，不能只一个，多次确定，至少两次推理

AI 机制

AI 调整之前需要先思考是否合理，而不是一味地直接按照用户的指令来，防止用户是傻逼。

而且输出内容应该先声明，经过我的判断，用户说的合理，可以调整。明确不是乱来的，让人放心！

如何维护多个项目的skill？自动维护！

自动维护提示词习惯。记住各种场景下的常用规则，直接复制粘贴，而不是每次都要手写。可视化管理规则，记忆

agent的评价

不是能一次性跑多久时长，质量＞数量

agent的竞争力

数据资产+生产力