有没有什么skill或者方法能够加强龙虾的记忆能力？对于学术党来说，要是能够帮忙整理论文 消化论文可就太好了 完全能够当个导师用。关键点还是记不住。前几天聊的东西马上就忘了。 1 个帖子 - 1 位参与者 阅读完整话题
No self-reporting. Only code. Built a platform that tries to infer what you know from your actual work. Comments URL: https://news.ycombinator.com/item?id=47815869 Points: 1 # Comments: 0
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下全是我自己手搓，没有ai味（我用最真实、最不绕、最直接的方式跟你讲 hhhhh），放心品尝 很多人以为 Skill 迭代最难的是"怎么改"。 但我越来越强烈地觉得，真正难的其实不是改，而是： 你改完之后，根本不知道它到底有没有真的变好。 补描述、调 prompt、加例子、补边界、改结构。 Skill 看起来越来越完整，文档越来越像样，语气越来越专业。 但问题是： 看起来更完整，不等于真的更强。 skill的实际行为未必更稳定，边界未必更清晰，失败处理也未必更好。 所以很多 Skill 维护最别扭的地方，其实不是"不会写"，而是你明明已经改了很多轮，却还是说不清： 上一次改动，到底有没有真正产生作用。 我后来专门跑了 100 个高下载 Skill，发现问题并不是"不能用" （是的，烧我自己的token）结果最有意思的地方，不是烂 Skill 特别多。恰恰相反，大多数 skill 其实都能用： 70 个通过 29 个在 caution 区间 1 个 fail 平均分 73.8 真正的问题不是：大多数 Skill 完全不能用。 而是 很多 Skill 停在一个很尴尬的状态：能用，但不容易被继续有效优化。 你一旦想认真往上修，就会发现问题不少，但很难判断到底该先修哪一块。 也就是说，难点不是"没法写"，而是 没有诊断，所以不知道怎么有效地继续改。 更关键的是，这种"不对劲"还不是随机的。 我看到的弱点主要集中在几个地方： Trigger quality 平均 6.2 Functional quality 平均 6.6 大约 80% 缺少 not_for 边界 大约 60% 的 D4 弱项 Skill 缺少像样的 error recovery guidance 还有接近 40% 更像"写给人看的说明书"，而不是"写给模型执行的操作说明" 这里翻译成人话就是： 很多 Skill 不是坏在"完全不能用"，而是坏在几个特别重复的地方：不会划边界，不会处理失败，也没有把行为写得足够可执行。 所以我后来做了 SkillCompass 我想解决的，不是"怎么把 Skill 写得更长、更完整"，而是另一件更关键的事： 在你动手优化之前，先看清问题到底在哪；在你改完之后，再验证这次修改有没有真的产生提升。 所以对我来说，SkillCompass 不是一个"给 Skill 打个分"的工具而已。 它更像一个给 Skill 迭代提供方向感的东西： 现在最弱的是哪一维 下一步该先修哪里 这轮修改有没有真的带来提升 有没有把别的地方一起改坏 【这里插一句compass 这个名字，指南针🧭，其实也是这个意思。不是替你做决定，而是先帮你定位方向。 】 所以它背后的设计原则也很简单： 本地优先 ：所有数据都留在本机，除非你明确要求，否则不会主动发起网络请求 默认只读 ：评估和报告默认不改文件，improve、merge、rollback 这类写入操作都要明确开启 被动追踪，主动决策 ：Hooks 会收集使用数据，但系统只给建议，不会自动替你执行 双通道交互 ：既支持键盘选择，也支持自然语言查询，两种方式始终都可用 同时我把评估分成了6个维度；把判定标准分成3档 它不是在帮你"多改一点"，而是在帮你把迭代变成一个可验证的流程 与其盲目地"再多写一点"，不如把 Skill 迭代拆成一个更清晰的 workflow。下面拿agile-product-owner作为一个例子展开讲讲： 1）先诊断 不要一上来就改。先看清楚最弱的是哪一维。 很多时候你以为问题在 wording，实际可能卡在 trigger、边界、失败处理，或者执行指令根本不够可操作。 先把最弱项找出来，后面的修改才不是瞎试。 接着它出一个初步的报告，包含维度1-3，后面会有一个完整的全方位维度1-6的测评报告（看下图）： 2）再看单项到底在说什么 我觉得这一步特别重要。 因为很多人一看到分数，会下意识觉得"哦，这项低，那我去多写一点"。 但 SkillCompass 真正有价值的地方，不是只给分，而是会把某个维度为什么高、为什么不满分、它到底在判断什么，说得更清楚。 比如拿 D6 = Uniqueness（独特性 / 不容易被替代） 来说，它看的不是"你这段话写得顺不顺"，而是在看： 这个 skill 是不是真的有独立价值 有没有明显重复品 跟相似 skill 重合度高不高 是不是一句普通 prompt 就能替代 它是不是很快就会过时 这里个skill的这一维最后给到 8 分，不是说它不好，而是说：它已经有明确领域专属性，也不太容易被普通 prompt 替代，但还没有强到"极其不可替代"的程度。 3）定点修复，而不是整份 Skill 重写 找到弱项之后，不是整份 skill 重写一遍。 而是只修最该修的那一块。所以我们把弱项加强，不好的修正，但不污染上下文 **这里要敲重点！！！**它做了那段分数解释，并且新版分更高的同时也没有把别的地方改坏，因为修改目标清楚，而且不会为了补一个问题，把别的地方一起搅乱。 此时，SkillCompass 已经完成这轮评估/优化结果的写入（提升了 D5），没有出现回归，然后把新的评估记录和最新扫描时间写进本地文件。 4）改完再验证，千万不要靠感觉收工 改完不能靠"看起来更完整了"就结束。要重新验证这次修改到底有没有带来真实提升。 分数有没有上去，解释有没有更扎实，别的维度有没有被改坏，这些都得重新看。 （（（兄弟们，有效的优化才叫"迭代"，不然就是屎上雕花。））） 5）再找下一个瓶颈 一个问题修完，不代表 skill 就完成了。 通常是这个瓶颈被拿掉之后，下一个瓶颈才会浮出来。 所以真正有效的迭代，不是一次性改到完美，而是持续地： 诊断问题 → 定向修复 → 验证提升 → 找到下一个瓶颈 这也是我现在更认同的一种 Skill 迭代方式：不是凭感觉打磨，而是把迭代变成一个更可验证的 workflow。 适合什么人，不适合什么人 适合： 任何在维护 agent skills，并且希望质量能够被量化的人 想要有明确改进方向的开发者—不是靠猜，而是清楚知道下一步该修哪个维度 需要质量门槛的团队—任何会改动 skill 的工具，都可以在改动后自动接受评估 安装了很多 skills、想看清哪些真的在用、哪些已经陈旧、哪些存在风险的用户 不适合： 通用代码审查或运行时调试 从零创建新 skill（这个更适合用 skill-creator） 评估非 skill 类型的文件 项目在这里： github.com GitHub - Evol-ai/SkillCompass: Evaluate agent skill quality. Find the weakest… 有兴趣的佬欢迎去 GitHub 点个 star 支持一下。 如果你手上也有自己的 SKILL.md，欢迎直接贴出来，我这边也可以顺手用 SkillCompass 帮你跑一遍测评。 有问题也欢迎一起聊，也可以 fork 回去自己改着玩 2 个帖子 - 2 位参与者 阅读完整话题
大佬们知不知道有没有什么mcp或者skill是了解整个项目的架构图，需要用来清理冗余设计？ 1 个帖子 - 1 位参与者 阅读完整话题
发现了提示词网站，他的前端界面，做的很漂亮，但是和我项目技术栈不搭，所以想要蒸馏为一个skill 就是这样提示词，gpt 都能写出这样页面来，感觉超牛的 佬们有没有什么好的项目推荐： motionsites.ai MotionSites — Premium Hero Prompts Your Design Al Superpowers In One Click 7 个帖子 - 6 位参与者 阅读完整话题
这是一个能够针对web应用进行js审计，根据接口进行渗透测试的sklii 目前来说，我用这个东西已经拿出过成果 但是希望更多的佬友能使用这个skill进行测试，并且给我一些优化建议 加纳 归档.zip (244.0 KB) 1 个帖子 - 1 位参与者 阅读完整话题
最近在用codex写论文，但是总感觉差点意思，想求助佬友们有没有推荐的写论文skills和mcp工具，求求了，拜托拜托 4 个帖子 - 4 位参与者 阅读完整话题
来L站半个多月从什么都不会学到了很多知识，感谢各位佬的耐心回复和公益佬的Token让我学到超多东西，始皇牛逼 目前还在调试中，好了就发。 6 个帖子 - 6 位参与者 阅读完整话题
有大佬用过office-cli这个skill吗？我今天晚上电脑不知道咋了，用着用着给我弹出来一个html文件 我看了一下这个文件前缀叫officecli 我怀疑是这个skill干的，但是我电脑啥也没干呀，也没开什么agent干活。不能是电脑被黑了吧 1 个帖子 - 1 位参与者 阅读完整话题
有没有佬友交流下，如何才能更好的运用Ai，有没有什么方法论，比如运用skill，mcp，Harness Engineering 可以交流下，怎么才能在工作中运用起来让脑子可以不那么累 2 个帖子 - 2 位参与者 阅读完整话题
mac 版 Claude App、vs code Claude 扩展、系统terminal版Claude（我也不知道这个叫啥） 我安装了 web-access 插件，系统 terminal 可以使用，vs code 扩展和 App code 模块都不能使用。 之前是 vs code 扩展和终端可以安装，code App 不能安装，可以使用。 找 claude 来来回回 消耗了很多时间都没解决掉。 有老哥遇到过类似问题的么？ App 系统都是最新版本 3 个帖子 - 2 位参与者 阅读完整话题
只会用codex 自然语言编程。但是写出来的ui都不太满意，所谓的skill压根不懂 3 个帖子 - 3 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 ai-repo-cleanup 地址： codex-skills/skills/ai-repo-cleanup at main · tiezhuli001/codex-skills · GitHub 这个 skill 是我在反复改 AI项目时做出来的。vibeCoding很爽，但是仓库很容易越改越胖，AI存在局部性，上一轮对话改了A，下一轮对话修改成B，那么A需求的历史代码和测试代码就很可能出现冗余。包括plan计划越来越多，有些plan计划已经和代码仓库不一致了。 目前我本地1.3w行代码，1.7w行测试代码的情况下，清理了近4000行无用的代码，聊胜于无吧，持续迭代下去，希望能真的好用。 long-run-execution 地址： codex-skills/skills/long-run-execution at main · tiezhuli001/codex-skills · GitHub 这个 skill是被codex逼出来的，做一半就开始总结、问我下一步的意见，经常夹断，十分难受。现在是要求把任务拆成可验证的小步，做完一块就验一块，然后继续往前推，直到真的完成或者真的被卡住。 我本地使用一般只要有执行计划文档，都能全部完成之后再结束，测试也比较完善，还算好用。定期用历史对话总计提升了几轮，也是希望能越来越好用吧。 希望能帮助到有需要的佬友 ，自取即可～ 1 个帖子 - 1 位参与者 阅读完整话题
我公司要求使用openclaw实现自动化生成买家秀的流程，用产品图做出来一组同背景，但不同角度的图片。 我自己用gpt写了一套skills，但总是出现产品结构错误。 我在网上也没搜到相关的skills，求助大佬帮忙 1 个帖子 - 1 位参与者 阅读完整话题
大家在用的hermes上有哪些好用的skills啊，可以让hermes越用越好用呢，最近在整理这些skills呢。 2 个帖子 - 2 位参与者 阅读完整话题
经过两个项目的洗礼skill，用起来还是比较顺畅的。 技术栈：后端 Rust Axum，前端 React Tanstack。 各位佬友若有需求可以用用看。 github.com GitHub - timzaak/web-dev-skills 通过在 GitHub 上创建帐户来为 timzaak/web-dev-skills 开发做出贡献。 1 个帖子 - 1 位参与者 阅读完整话题
马上要交毕业论文1稿了，不想把钱浪费在查重上，有没有什么好用的skills可以使ai写论文的时候查重率变低。 1 个帖子 - 1 位参与者 阅读完整话题
有合适的Prompt或者skill可以解决这个问题吗 1 个帖子 - 1 位参与者 阅读完整话题
如题，目前我用claude code浏览器自动下载的话，学校ip问题总是触发cloudfare的验证，claude一看到立马就停止不干了，所以还不如直接调用scihub 3 个帖子 - 2 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 作者最近都在一家小公司一个人做全栈开发，这期间有了不少新的思考和感悟，在这里写下来分享给大家。 正文 这阵子所有 AI 工具都在卷「帮你更快」------更快写代码、更快做方案、更快下判断。我反过来做了一个东西： 让你更慢 。 为什么？因为我越用 CC、Codex 这些工具，越有一个隐忧： 我的代码写得飞快，但我自己的判断力、品味、抽象能力反而在退化。 遇到问题我第一反应是「让 AI 试试」，而不是「我先想想」。长此以往，当所有人都拥有同样强的 AI 时，能分出高下的就是那些 没把思考外包出去的人 。 所以我做了 growth： https://github.com/zhu1090093659/growth 这是什么 一套 skill，装到你的AI工具箱里面。它不会替你写代码，只会在你准备写代码之前、之中、之后， 把你没想清楚的问题一层层剥出来 让你细细品味，获得真正的经验。 它只干一件事： 问问题 。 四个 skill Skill 什么时候用 它会问什么 taste-audit 代码/设计写完了，想知道写得好不好 这东西美不美？哪一行你其实不太想给别人看？ intent-refine 有个想法但说不清，想定义需求 你到底要什么？为什么要？做完之后什么可观察的东西会不同？ judgment-redteam 做了个决策，或倾向某个方案 你哪里可能是错的？一个比你聪明、不同意你的人会说什么？ abstraction-uplift 代码 work 了但感觉结构不对 有没有东西被绑在一起但本不该绑？有没有抽象层其实是多余的？ 真实交互示例 这段是测试 taste-audit 时的实际对话，能让你感受一下味道： 我 ❯ 帮我看看这段代码写得怎么样？ [贴了一段 200 行的 Python 类] Claude ❯ 先不谈技术——你读这段代码的第一感觉是什么？ 一个词形容。 我 ❯ 还行吧，能跑 Claude ❯ "还行"是真没感觉，还是感觉没想清楚？ 你再读一遍，这 200 行里，有没有一行你其实不想让别人看到？ 具体是第几行？ 它不评价我的代码，它把我逼回到 我自己的感受 。而且它不接受"还行"这种含糊的退出------这是刻意设计的。 核心设计：三条铁律 每个 skill 开头都写着，AI 必须遵守： 1. 镜子原则 ：禁止说"我觉得应该 XXX"，只说"你觉得这里怎么样？" 2. 苏格拉底纪律 ：只问问题不给答案，问题分三层锋利度（激活 → 刺破 → 重构） 3. 抗柔顺原则 ： 用户感到舒适 = skill 失败。用户感到被挑战 = skill 成功。 第三条最反直觉也最关键。大部分 AI 工具的产品经理都在优化"用户满意度"，但思考训练这件事，让你满意就意味着训练失效了。 跟 nuwa-skill 的区别 前阵子我看到有佬友分享过 nuwa-skill （蒸馏芒格、马斯克、Naval 的思维框架），我觉得那是个很棒的项目。growth 跟它正好是光谱的两端： nuwa-skill ：蒸馏 别人 怎么想 → 让你拥有更好的顾问 growth ：蒸馏 问题 本身 → 让你成为更好的自己 这是两种路线，客观的的说我觉得都挺好的，但是如果可以的话，我还是想让自己变得更好，嘿嘿。 顺便说一下这不适合谁？ 如果你就是要 AI 快点帮你写完收工， 别装 ，会烦你。 如果你习惯"AI 夸我写得好我就开心"， 别装 ，它不会夸你。 如果你需要的是标准答案而不是自己思考， 别装 ，它一个答案都不给。 适合谁： 对「AI 让我变废」这件事有警觉的人 做技术决策时想要一个主动挑刺的对手 想训练判断力/品味但不知道怎么练的人 版本说明 目前是 v0.1 公开实验 。问题库是我根据自己这段时间的经验攒的，还没经过大量实战验证。预计未来会基于反馈不断修改。 所以**如果你试用后有感受------不管是"这个问题正中我要害"还是"这个问题纯废话"------都欢迎来 issue 或 PR **。v0.2…v0.x 就靠大家的反馈演化。 链接 github.com GitHub - zhu1090093659/growth 通过在 GitHub 上创建帐户来为 zhu1090093659/growth 开发做出贡献。 最后一句也是 README 里写的： 如果 growth 让你的判断力变强了，记得别再依赖 growth，那就是毕业的时候。 训练轮终究是要扔掉的。 2026.04.17 随笔 4 个帖子 - 3 位参与者 阅读完整话题