yidinghe

用多 agent 的人根本不在乎设计，也没有精力去思考几万行代码的细节，只想快点搞完。

自然语言的模糊性是天生的，我会直接说 “在 A 库的 B 表中找 status 为已解决的记录”。

直接列出来啊

1. open-source-playbook — 当你有开源目标但没具体任务时，用来诊断项目阶段并路由到后续技能。
2. repo-bootstrap — 从零启动一个仓库或把内部代码发布为开源，包含发布前的敏感信息清理。
3. license-and-legal — 选择许可证、DCO vs CLA 、代码复用/再许可、判断能否使用他人代码。
4. api-design — 设计不可撤回的公开接口，涵盖弃用策略、稳定性保证和 CLI 体验。
5. testing-strategy — 解决测试套件缓慢、不稳定或缺失的问题，让陌生人一条命令就能跑起来。
6. code-review — 审查 PR （包括大规模未 solicited 的 PR ），以及温和地关闭不合适的 PR 。
7. refactor-safely — 安全重构其他人依赖的代码，采用绞杀者模式、codemods 等策略。
8. performance-benchmarking — 做出可辩护的性能声明，或审查别人的性能测试。
9. ci-pipelines — CI 太慢、不稳定或在 fork PR 上失败时的修复方案，含矩阵优化和安全注意。
10. release-engineering — 版本管理、changelog 编写、带完整性的发布流程，以及回滚坏版本。
11. supply-chain-security — 编写 SECURITY.md 、处理漏洞报告、固化 Actions 、签名和维护者交接。
12. dependency-hygiene — 控制依赖膨胀、减少升级混乱、让 Dependabot PR 不再无人问津。
13. readme-that-converts — 让人能在 30 秒内看懂你的项目到底是做什么的。
14. docs-architecture — 文档膨胀后的治理，含 Diátaxis 框架、版本管理和示例测试。
15. issue-triage — 管理失控的 issue 积压，通过标签、模板和不伤人的关闭消息来疏导。
16. contributor-experience — 有人 star 没人贡献时，诊断转化漏斗哪个环节出了问题。
17. launch-and-growth — 发布推广项目的最佳实践，包括 Show HN 礼仪和真正有效的转化方式。
18. governance-and-sustainability — 决策机制、应对倦怠、资金、fork 处理，以及如何负责任地逐步退出

我没有囤积同一品牌键盘的爱好，所有键盘都是不同牌子的。现在有两个键盘在吃灰，一个是有几个按键不够灵敏，一个是分离式人体工学用不惯，都属于不好用但没坏，所以留着万一需要拿来应急。

1. 没看到所谓的“后续签约”内容，你说的应该是另外的事情，搞混了。
2. https://x.com/tianyi/status/2083519855203078320 帖子原文说的是“请附上 GitHub id 以及开源代表作。” 我看不出有过分的地方，如果你连 agent 开源项目都没有，你就没必要参加内测对吧。

你这三个帖子效果都不好。当然我不是说非得整什么“强迫女友学 AI”，而是没有亮点。想在 V 站介绍东西，那就三句话内讲清楚：

1. 我这个产品叫 knowhere ，是一个知识库。
2. 我做这个产品的目的，是要让所有 Agent 都能具备顶级的文档搜索能力。
3. 我提升搜索结果质量的方法是：三通道搜索+RRF+两阶段 ranking+Agentic 排序。

然后就把效果展示出来，告诉大家“这个东西值得你用”，最后就是 quick start guide 。

@isbase 问题是国内有好的模型就是不肯用。

听她倾诉，然后带让 AI 帮忙应对职场问题。你觉得她的压力期只在眼下吗，很有可能不止哦。

@andyskaura 哈哈你这是人身攻击了，性质不一样，当然如果是对别人，我估计给不了这么多哈哈，，，以后多养成对事不对人的习惯吧