和 spec 驱动差不多？

公司开的 cursor ，这个月已经 100 多刀了

vscode 族群 https://i.imgur.com/agAJ0Rd.png 现在用 cursor

@linhey #8 看了，我们一个微前端 app 入口 50 多个依赖包，依赖包还有依赖包，业务组件都是封装抽离的，构建注入这套不现实，在看 bippy 动态注入的方案了

skill 本身就是个 tool ，也就是个 mcp 协议的东西

@linhey #5 组件在依赖包里怎么办，发到生产包的总不能编译时注入 debug-data 属性吧 https://i.imgur.com/MAyk5GN.png

@Chuckle 只改 app 的构建，能做到给安装的依赖包产物里的组件加上 data-***的额外信息么

最近刚好也需要个从页面元素定位到源码的方案，为的也是 AI 能知道要改哪里、影响范围评估等等。
umi+qiankun 微前端，要改的东西都在独立包里，app 工程就是个页面入口，有时候套快 5 层包人找起来很麻烦，本地只跑 app 的 source map 也没用，安装的包产物都是服务器构建出来的，构建时在节点上注入大量信息也不太行，除非每个包都构建两个版本，构建生产 app 用的 和 开发时带信息的产物。
我现在做法是提取 dom 特征节点（还是有注入一些特殊属性的）、url 路径等元信息，克隆所有的几百个包到本地，让 AI 自己先暴力找，确实能找到，就是慢，也费 token 。优化的话，找到了就把信息落向量数据库里，类似 RAG 一样，特征信息变动还是少的，特征节点嵌套结构也稳定，下次找就快了，至少能快速找到对应包工程，再去定位具体代码。
不过，如果从 React 本身入手，模仿 React Scan 运行时注入应该更好？
另外 AI 写代码确实好用，就是测试起来太麻烦了，很难自闭环，业务链路长又大，e2e 测试的时候没数据，或者接口报错，AI 能自己 call 后端，或者自己造、自己修（

光结构化替换的话信息本身没变，对 AI 来说没区别，要是塞多无用中间代码，200k 上下文里就 1k 有效代码的话，信息多了，对 AI 才有点麻烦

nestjs ，司内内部服务、监控之类的都用它，业务还是用 java

哪有平白无故的便宜，就差库克做苹果 ai 都得买中转了

思路不错，大模型缺少的始终是信息，无论是提示词工程还是知识库，都是为了更好地给大模型提供信息，剩下的就是相信大模型本身的计算能力了，我也在考虑将信息抽象若干层，当然这个若干层不能是人定的，而是用模型学习计算出来的，形成一张可扩展的、有层次的信息地图。让大模型能够自由寻找。这有点像人脑的记忆结构，人脑也会压缩记忆信息，回想起来的时候，往往只是模模糊糊知道大概发生了什么，有什么人、做了什么事之类的，如果需要想起来，可能会去找照片、录像、日记等等。

有上下文可以回滚，不过就怕是命令删除、清空了文件，这种文件内容不在上下文的，或者上下文已经被压缩了，就寄了，话说现在这些 agent 为啥不考虑搞个备份机制，每次对现有文件的写操作都先把原文件备份到一个地方，这个地方设置个 50g 也够用了吧，新的替代旧的

clash x pro 无问题

@capgrey 嗯，抓包看了下，mcp 是 schema fc ，skill 也放在 tools 里，看起来就是预设提示词，很灵活，大模型要了之后才把对应的 skill.md 读给大模型，神 token 啊

那感觉要是团队协作的话，能搞个类似 git 的工具呀，记录每个人产生的 AI 改动及对应的对话啥的，然后每次对话结束都让 AI 自己总结这个项目注意的点，AI 对话时容易出错的地方等等到一个 markdown 里，不断迭代，这个项目就越来越被 AI 熟悉了？就是感觉久了之后仓库大小会爆炸。。。。https://i.imgur.com/N9E3iZ2.png

@povsister 怎么说呢，好像也没有比这更好的设计了 https://i.imgur.com/NIvxivj.png 大模型 API 好像有个通用的 oneAPI 来着，看消息格式也是老熟悉的 schema 呀 https://i.imgur.com/NtlrLSd.png

cursor 的回答，看起来大差不差。

1. 一堆 Markdown + 「描述每个干啥」+ AI 挑着读？
对，就是这么设计的。

Cursor：.cursor/rules/ 里每个规则是 markdown （或 .mdc ），用 YAML frontmatter 写：
globs：匹配哪些文件时这条规则生效
description：这条规则在什么情况下有用
alwaysApply：是否每次都带
客户端/Agent 根据「当前对话涉及的文件 + 描述」决定哪些规则被加入本次请求，相当于「按需挑着读」。

Claude Code：.claude/rules/ 里也是多份 markdown ，可以用 frontmatter 的 paths 做路径匹配，只有命中当前工作文件时才加载对应规则，同样是「按需」。

所以：有结构的 markdown 组合 + 用 frontmatter/描述说明「每条干啥、何时用」+ 由客户端/Agent 根据当前上下文决定带哪几条，这个理解是对的。

2. JSON 是干啥的？给 AI 读还是给代码读？
两种都有：

给人/给 AI 的说明：很多项目里会有 README 、CONTRIBUTING.md 、AGENTS.md 等，是自然语言 + 一点约定格式（比如「## 规则」「## 命令」），主要给 AI 当说明读。

给程序读的配置：
Cursor 的规则列表/索引可能用配置（不一定是裸 JSON ，也可能是 YAML ）记录「规则文件路径、glob 、描述」等，客户端代码读这些配置，决定本次请求要附上哪些规则、以什么顺序。
Claude Code 的 .claude/settings.json 是结构化配置，给 Claude Code 客户端读，不是给模型当「正文」读的。

所以：JSON/配置 = 给客户端程序做「规则调度、匹配、优先级」； markdown = 给模型当「可读的规则/说明」。模型主要吃的是 markdown 内容，不是 JSON 结构本身。

3. Markdown 里是「没特定结构的自然语言」吗？
不完全是。通常会有约定俗成的结构，但不是严格 schema：

常见区块：项目概述、常用命令、目录结构、命名/代码风格、禁止事项、示例等。

仍然是自然语言句子 + 列表 + 代码块，没有强制「必须有哪些 key 」的 JSON 式结构。

有的客户端会约定简单 frontmatter （如 globs 、description 、paths ），其余正文自由写。

所以：半结构：有惯用区块 + 自然语言描述规则/规范，不是完全无结构，也不是完全像 API schema 那样死板。

4. 目录结构：.claude 、.cursor 、AGENTS.md 等
是的，各客户端有自己约定的目录/文件：

Cursor：.cursor/rules/（多条规则）、历史上有 .cursorrules 单文件。

Claude Code：.claude/（如 settings.json ）、.claude/rules/、根目录 CLAUDE.md 。

通用/多客户端：很多项目会放 AGENTS.md 或 README 里写「给 AI 的说明」，谁支持谁就读。

所以：是的，大家会把「给 AI 用的东西」按各客户端的约定放到特定文件夹（如 .cursor 、.claude ）或根目录固定文件名（如 AGENTS.md ），不同客户端各读各的。

5. 调外部能力：HTTP 还是 stdio ？谁发请求？能力谁提供？
两种都有，而且「谁发请求」要分清：

MCP （ Model Context Protocol ）里常见两种传输：
stdio：和本地进程用标准输入输出通信（例如本地 MCP server 、本地后端）。
HTTP：和本地或远程 HTTP 服务通信。

谁真正发请求：
模型只做决策：「我要调某个 tool （例如 get_hitokoto ）」。
真正发 HTTP 、读文件、执行命令的，是 AI 客户端（ Cursor/Claude Code 等）或 MCP 客户端。
客户端根据「当前可用的 tool 列表 + 模型选的 tool + 参数」去执行：发请求、调 MCP 、跑 shell 等。

Markdown 里写啥：若你自己写一个 MCP server 或 HTTP API （比如「一言」），一般会在规则/文档里写：请求地址、方法、入参/出参长什么样，这样 AI 在「工具描述」或上下文中看到后，才知道该选哪个 tool 、传什么参数。工具本身的 schema （名字、参数、描述）往往由 MCP server 或客户端配置提供，markdown 更多是补充说明、示例、注意事项。

所以：通信方式 = HTTP 或 stdio 都常见；发请求/读写文件/执行命令 = 客户端或 MCP 客户端自带或通过 MCP 获得； markdown 里写请求地址、入参出参是为了让 AI 正确选择并填写参数。

6. 和 AI API 发请求时传啥？「按需传」怎么实现？
传的是「一串」多段内容，但不会无脑全塞：

发给模型的大致组成：
系统提示（含「你是什么、默认行为」）；
被选中的规则/文档（上面说的「挑出来的」 markdown 等）；
对话历史（可能截断或摘要）；
当前用户消息；
有时还有「当前打开/选中的文件」等。
这些在客户端里会拼成一条或几条消息（例如 system + user/assistant 轮次），本质上就是字符串（ token 序列），再加上校验、会话 id 、模型参数等 API 元数据。

「不能一股脑都传」怎么办：
规则/文档：用 globs / paths / description 做匹配，只把「和当前编辑文件、当前问题相关的」规则附进本次请求；
代码库：用语义检索（ embeddings + 向量相似度）或路径/符号索引，只取「和当前问题最相关的片段」放进上下文；
对话历史：超过一定长度就截断、摘要或滑动窗口，保证不超模型 context 上限。

所以：和 API 交互时，除了鉴权、会话、模型参数，主要就是在传「选好的规则 + 选好的上下文 + 对话」组成的字符串；按需传 = 客户端用匹配规则 + 检索/索引 + 历史裁剪，只把「用得上的」塞进这次请求，而不是把整个仓库和所有规则都塞进去。

别吵了，前后端都用 js 吧，开发起来绝对快 https://i.imgur.com/agAJ0Rd.png 我们这是真前端自己用 nestjs 写低代码、监控之类的后端