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 写低代码、监控之类的后端

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

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

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

另外有没有好用的画图软件，目前用 Draw.io ，有 vsc 插件可以打开.dio 文件是方便，但 Draw.io 各个元素之间太独立了，画好后要在中间某一部分插一点东西，拖动调整起来麻烦。

让 ai 定期扫代码库，生成代码流程图的，代码各个大大小小的函数调用链路倒是清楚，但太细了，ai 自己加的业务理解和业务流程还是有较大偏差，更有些完全幻想出来的流程，毕竟是靠函数、变量名、乱七八糟的注释推理的，作为给人看的东西还是勉强了。

看看这个表格？用的就是 css-grid https://comcast.github.io/react-data-grid

认识个人，企业版 cursor ，一天能干 60 刀，我一天最多干 5 刀，可能我们这没开 max 模型权限原因吧，token 消耗少

@Chuckle vue 里一堆 any 那是没得救的，emit 的 n 种类型写法，不知道匹配到啥的 function call 参数，没人维护的 inject 类型。reat 里要是一堆 any ，函数泛型慢慢拆，时间问题。自己项目 vue 干得快，多人的公司的项目，必须 react ，但我感觉现在这哥三框架，用着都多多少少有不得劲的地方

react 业务逻辑拆 hook 里，但是很难受的就是，业务逻辑往往又是多变多情况的，很可能今天封好，明天别人看不懂或者不好原地改，只能 cv 一个副本拿去用，而且拆得越多，写 props 和传参 n 层就非常麻烦，也不好维护一堆 ts 类型，这个倒是可以用状态管理解决，但那种多个地方用的组件，因为要用 context 隔离状态其实也挺难受的。vue 的话，vsc 插件太卡了，ts 服务经常也挂，一堆堆的语法糖，公共组件 v-model 和 emit 那套处理起来可比 react 麻烦多了，单文件行数爆炸，类型维护也难，但整体还是比 react 写法规范点，毕竟语法糖限制死了，react 里可见到太多把 hook 玩出花活一层套一层的了，我现在拿 vue 的响应式和 react 结合起来玩，写了个类似 valtio 的东西，清爽很多。react 的文档啊，其实能教的也都教了 https://i.imgur.com/agAJ0Rd.png 但保不齐有人玩花活整点 js 里要动脑子的技巧。

还是更喜欢用装饰器一点，更灵活，堆叠也比函数嵌套调用直观好写，ts 的装饰器本质上也就是把 class 构造器、函数给传了进去，所以既可以 @装饰也可以直接函数调用 https://i.imgur.com/agAJ0Rd.png 遇到需要运行时的动态注入，装饰器也可以封装出更简单的语法糖

那肯定得有地方存这些 md 吧，用咱这个 vsc 插件吧，https://github.com/qxchuckle/vsc-drafts ，平时一些简单脚本、项目记录、画图啥的我都扔草稿本里 https://i.imgur.com/agAJ0Rd.png

能信任编译器的输出结果，那是前人从二进制驱动机器以来的智慧和努力啊 https://i.imgur.com/agAJ0Rd.png 前面的一切都是数学和形式化方法的结果，别人已经关心过了，现在也有人持续的在关心，输入输出的无数可能都已经覆盖完了，多少测试覆盖支撑着这份信任。
而大模型底下是概率抽样，让它写代码，说白了，就是赌风险和收益嘛，还发明个 vibe coding 名词来掩盖放下点责任心想轻松点的人之常情。当然，业务代码里随手写的工具函数，正常来说也不会去做充足的测试、校验、错误处理，反正要字符串不会来个对象就行了，炸了再热修也行。
当然我是觉得，业务代码不可能人不看的，不看那就是用户替你去看了，出了问题特别是像钱算错了，背锅的只能是人啊。现实点，ai 总是接手现有的项目的迭代吧，一个 id 字段在不同对象里几十种意思，ai 啥时候能自己去问 git 历史提交的人？当然，有些面向司内的东西，已经是 ai 开发了，反正没风险。