怎么做
用 /skill-creator 问 Opus 4.6 会不会 Hoare Logic/equational reasoning，生成 SKILL.md
怎么用
安装好 SKILL.md 后，让 Opus 自己去用。用 Sonnet 也有一定效果。
有什么用？
对于 TypeScript 来讲可以显著减少代码里的防御性编程，提升代码里的函数式味。
各位可以试试，把结果反馈在这里
1 个赞
只用sonnets 4。6的飄過 
对于用量里没 Opus 的 Claude Code 用户可以试用我预生成的 skill
内容完全由 Claude Opus 4.6 生成，我只对内容的有效性做基本限度内的检查，不对有效性或应用该 skills 文件造成的损失负责任。
感觉用在别家模型上效果甚至会比用在A社模型上效果更好，因为A社的是dense模型，别家是MoE，你提到Hoare Logic/equational reasoning说不定能显著增加激活的专家数量（）
大佬, Anthropic 用 dense 模型这个消息可以在哪知道 
我只是听到大家都在这么说orz。你搜索is claude sonnet/opus dense or moe model也能搜出不少相关消息，但我不清楚准确性，不过A社这么久也没出来辟谣估计也差不离了
1 个赞
我认为这个skill起作用的先决条件是不能出幻觉。其他都是次要因素。
其他的主要影响因素取决于模型对于写证明的熟练程度。以及是否有配套测试兜底一些特殊条件。
1 个赞
幻觉真的靠模型素质。个人感觉A社的模型算最好一档的了，gemini最次（
复盘记录：2016年Q1卡券系统渠道接入 —— 模型生成代码的模式局限与对策
1. 核心主旨
模型与模型关系，限定上下界与边界规范生成模型的行为与相关的输出质量。
具体展开：
- 模型与模型关系：指代码生成模型与业务领域模型（卡券状态机、渠道协议模型）之间的映射与约束关系
- 限定上下界：明确模型输出在代码结构、业务流程、异常处理等方面的允许范围与禁止行为
- 边界规范：定义生成代码与现有系统之间的接口契约、数据结构对齐、状态一致性等边界条件
- 输出质量：通过上述限定，确保生成代码具备可读性、兼容性、正确性与稳定性
2. 困难（为什么需要这个目标 / 遇到了哪些问题）
-
困难 1：对 AI 模型的认知存在偏差，认为其具备真正的思考能力，从而让渡了决策权
- 开发者或管理者误以为模型能理解业务意图并做出合理判断，过度依赖生成结果
- 放弃了必要的人工审核与决策干预，导致错误代码直接进入生产环境
-
困难 2：在上下文的内容定义及其边界定义上出现偏差
- 模型对输入上下文中哪些信息是核心约束、哪些是背景说明的区分能力不足
- 边界定义模糊：例如，模型难以判断某个业务规则仅适用于特定渠道还是全局通用
- 导致生成代码时，要么过度依赖局部信息而忽略全局边界，要么将边界外的内容错误引入
-
困难 3：模型训练方式与奖励机制带来的副作用
- 训练语料和奖励函数倾向于鼓励“详尽输出”，导致模型容易生成过多细节
- 例如：在生成核销代码时，加入大量不必要的日志、注释、冗余校验，干扰核心逻辑
- 相反，在某些边界条件下，模型又可能生成过少内容
- 例如：未生成必要的异常处理或状态回滚逻辑，导致系统脆弱
- 训练语料和奖励函数倾向于鼓励“详尽输出”，导致模型容易生成过多细节
-
困难 4：模型不具备概念能力，无法理解概念与各种抽象的抽象模式
- 模型无法真正把握“幂等”、“最终一致性”、“分布式事务”等概念的内涵
- 因此，在生成内容时过度依赖于类比（即从训练语料中寻找表面相似的片段进行模仿）
- 然而，模型生成的文案与人类自然语言/代码风格高度相似，人类往往会以“文学/常理”的角度去理解这些输出
- 这种理解角度与实际的概念逻辑产生错位，导致概念混杂（例如，将“重试”类比为“反复敲门”，从而忽略了幂等性约束）
- 最终严重影响到生成代码的质量（逻辑漏洞、边界缺失、抽象层级混乱）
3. 克服困难的方法
针对困难 1：使用者需加深对模型的了解，明确自身角色与目标
- 第1点：使用者需要系统学习所使用模型的能力边界（包括技术原理、常见失败模式、输出特性）
- 第2点：明确自己在工作流程中的角色定位——决策者、审核者、概念工程师，而非被动的内容接受者
- 第3点：明确使用模型要达到的目标，且目标需足够细节
- 细节并非指单一技术点，而是指：理解模型在当前工作内容中“能为你做到什么”以及“不能做到什么”
- 例如：模型能快速生成符合常见模式的代码片段，但不能保证业务正确性；能写出幂等框架，但不能理解业务上的幂等语义
- 第4点：基于上述理解，主动调整期望值，重要决策（状态变更、资金操作）必须由人工最终确认，绝不让渡决策权
针对困难 2：这是最难克服的困难
原因：模型是基于上下文以算法概率生成数据的；其生成的数据会同时成为新的上下文，导致边界呈指数级扩散；边界的定义质量直接决定模型生成内容的质量
解决方法：设计一个“边界模型”
- 第1点：围绕任务相关的数据，明确其边界——定义独特的特征、概念、数据
- 第2点：基于这些边界，构建边界模型，用以指定：哪些信息属于当前任务的核心上下文，哪些属于外部参考
- 第3点：在生成代码前，使用边界模型对原始上下文进行过滤和重组织，只将边界内的信息传递给生成模型
- 第4点：注意：AI模型本身无法理解“处理规则”或“边界定义”，但上下文的内容可以影响其输出边界。因此，边界模型必须以“显式标记”的方式嵌入到上下文中（例如使用特殊标签、元数据），而非期望模型自行理解边界规则。对于边界模糊或跨边界的内容，人工介入明确归属，并将处理结果反哺给边界模型，持续优化其标记规则。
针对困难 3：深刻理解训练奖励机制对输出数量的影响，并采取针对性措施
根源分析：
- 训练阶段的奖励函数通常是一个概括/提纯函数，它要求模型将大量数据与核心目标进行匹配。输出内容越多，匹配成功的概率越高，因此模型天然倾向于详尽输出（生成大量细节）。
- 一旦进入惩罚模型阶段（如RLHF中的惩罚项），评定函数变为“以输出与既定目标的偏移距离为标准”，输出越多则偏移可能越大，模型转而倾向于减少输出。
- 这种机制导致模型在“过多”与“过少”之间剧烈摇摆，很难自动找到平衡点。
克服方法（注意：无法改变已训练完成的模型内部参数，只能从使用层面引导）：
- 第1点：使用者必须对自己需要生成的内容的规模、重点核心做到详尽了解，绝不能泛泛而谈。例如，明确本次生成应包含几个核心函数、每个函数的代码行数范围、必须覆盖的关键逻辑（如重试、幂等、回滚）。
- 第2点：在提示词中明确给出输出规模约束，如“生成代码不超过150行，核心状态机逻辑不少于30行，异常处理代码不少于5行”。
- 第3点：使用正反例约束：提供“过详细”的负面例子（如包含大量冗余日志）和“过简略”的负面例子（如缺少异常处理），并要求模型避开这些模式。
- 第4点：采用迭代生成策略：首先生成代码骨架（只包含核心流程和状态迁移），要求模型控制输出量；然后在骨架基础上分步补充细节（如异常处理、日志、注释），每次只扩展一个维度。
- 第5点：生成后使用自动校验器检测“过多”指标（如注释行占比超过30%则裁剪）和“过少”指标（如缺少try-catch则强制追加），形成闭环。
针对困难 4：AI不具备真正概念理解，只是模式匹配算法，其语料多为文学类比，需通过提供骨架来引导
根本原因：
- AI模型不具备真正意义上的概念理解能力，它只是一个在一定范畴内进行模式化匹配的算法。
- 其数据来源于语料，而语料通常属于文学概念范畴，充满类比（例如“重试像反复敲门”）。
- 因此，在使用设计模式等抽象概念时，AI极易因语料污染而生成与真实意图完全不同的内容。
克服方法（核心：控制上下文，提供基础设计骨架，以类比方式引导）：
- 第1点：使用设计模式时，务必提供最基础的设计模型骨架（如类图、核心接口、状态迁移伪代码），并以此作为类比范例，引导AI在骨架上进行填充，而非让AI自行发挥。
- 第2点：控制上下文规模——AI的上下文极其有限，即使能无限扩展，过多的上下文也会造成语料污染（无关信息干扰核心目标）。因此，只将最核心的骨架和关键约束输入模型，删除所有可能引起类比的冗余背景。
- 第3点：明确告知模型“不要使用类比解释，直接按照给定的骨架生成代码”。例如：“这是一个幂等控制器的骨架，请只补充具体的方法实现，不要添加额外的重试策略或日志。”
- 第4点：对于复杂设计模式（如状态模式、策略模式），人工预先定义好模式的参与者和关系，以结构化方式（如表格、JSON）提供给模型，减少模型自行“联想”的空间。
- 第5点：生成后，由人工检查是否混入了无关的类比性代码（如注释中的“就像…一样”），并及时清理；同时将正确的模式实现作为正例加入提示库，逐步减少语料污染的影响。
以上为使用AI进行正常开发中遇到的问题与复盘。
PL理论应该是不能提升，大概率为训练代码中有对应的方案触发了相应的生成模式。
人类大语料中什么都有啦。
在我用ai记录我口述的时候 它产生各种幻觉 数据 到 代码，然后反证上面观点的时候 其实也很好笑🤣。
不过有个地方我有点不同看法。你说"PL理论应该是不能提升"，但我理解你的意思其实是：模型的能力天花板是固定的，但使用者的"概念工程能力"是可以练的。比如你现在写这篇复盘，本身就是在提炼一套"怎么跟模型正确对话"的方法论，这东西下次用就能避开同样的坑。
我的意见是，人工参与越多，幻觉越多。不止模型会有幻觉。