Chuckle

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

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

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

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 吧，开发起来绝对快 我们这是真前端自己用 nestjs 写低代码、监控之类的后端

@air1314 是公司号，先换成 sonnet 用用吧，主要不知道这 token 咋算的，其它都 0.几刀

正确的姿势？ cursor 开 opus4.5 ，用量付费先设个 1w 刀额度。没错，ai 编程=花钱编程，所谓各种技术啥的就是大力（上下文）出奇迹，简单点，每次把你写好的提示文，复制粘贴几次再发送，效果都能有明显提升。

想不到有啥必须重写的，pc 手机上那堆常用软件都是重业务的东西，生态和数据绑死，技术还是其次，除非流程跑不下去了、变动大，或者性能撑不住，否则没理由冒着业务风险去重写（定 kpi 让 ai 重写这种意外情况除外），其次对于重业务的系统，ai 加持效率提个 10%已经算多了，代码、业务流程、行业黑话之间关系还是得人一步步梳理。不过程序员的那堆工具、**笔记、**助手这种东西肯定是越来越多的。