非必要不抽奖！！！非必要不抽奖！！！非必要不抽奖！！！ 2 个帖子 - 1 位参与者 阅读完整话题
我这算炼化codex嘛 1 个帖子 - 1 位参与者 阅读完整话题
-> -> -> -> -> 被炼化了 2 个帖子 - 2 位参与者 阅读完整话题
老项目的屎山代码很多，功能模块庞杂，让 codex 改代码偶尔会出现漏改，或动了本不该动的代码，所以整个项目需要先炼化后再 vibe coding. 使用 /goal 命令就很合适，把整个项目炼成 skills AGENT.md 再搭配手中的工作流 spec/superpower等等，codex再写起代码来能更精准，思考会更全面。 注意：需要开启 subagent 和 goal 功能,搭配 gpt-5.5 xhigh 效果更好，我试过用 5.4 也可以 但是炼化出的 skill 没 5.5 数量多和细节更完整。 /goal 你的任务是基于当前项目代码库，使用多路 subagent 和 $skill-creator 并行梳理项目知识，补充或完善开发过程中 AI 需要依赖的 `.agents/skills/` 与 `AGENTS.md`，目的是后续 AI 在修改、重构、排障、测试、扩展功能时能更准确理解项目，避免 AI 出现遗漏、重复造轮子、破坏既有架构、重复求证和错误假设等问题。 核心要求： 1. 始终保持当前环境允许的最大并发 subagent 数量。 2. 只要存在可独立分析的模块、目录、技术栈或开发场景，就立即分派新的 subagent。 3. 不要让 subagent 做重复工作；每个 subagent 必须有清晰边界、输入范围和预期产出。 4. 所有结论必须来自现有代码、配置、文档、测试、提交记录或可验证的项目事实，不允许凭空编造。 5. 优先补充对后续 AI 开发最有帮助的信息，而不是写泛泛的项目介绍。 第一阶段：主 agent 快速盘点项目 - 查找并阅读现有的 `AGENTS.md`、`.agents/skills`、README、docs、package/build 配置、测试配置、CI 配置、主要入口文件。 - 用 `rg --files` 或等价方式建立项目结构认知。 - 识别项目的主要技术栈、运行方式、测试方式、代码分层、核心业务域、关键模块和高风险区域。 - 基于盘点结果拆分 subagent 任务。 第二阶段：并行分派 subagent 根据项目实际情况，将以下方向拆成多个 subagent 并行执行；如果某方向不存在则跳过，如果某方向过大则继续拆分： - 架构与目录结构：分析项目整体分层、入口、模块边界、核心数据流。 - 本地开发与构建：分析安装、启动、构建、环境变量、脚本、依赖管理。 - 测试与质量保障：分析测试框架、测试命令、fixture、mock、覆盖重点、常见失败原因。 - 前端/UI：分析组件组织、样式系统、状态管理、路由、交互约定、设计约束。 - 后端/API：分析服务边界、路由、控制器、业务逻辑、错误处理、接口契约。 - 数据层：分析数据库、schema、迁移、ORM、缓存、存储、数据模型约定。 - 集成与外部服务：分析第三方 API、认证、支付、消息队列、文件存储、邮件等。 - 安全与权限：分析鉴权、授权、敏感信息、输入校验、权限边界。 - 运维与发布：分析 CI/CD、部署、配置、日志、监控、故障排查路径。 - 既有工具与复用点：找出现有 helper、utils、hooks、services、组件库、脚手架，避免后续重复实现。 - 历史文档与隐性约定：从 docs、注释、测试、配置和命名中提炼项目约定。 每个 subagent 的产出必须包含： - 分析范围：读了哪些目录、文件、配置或测试。 - 关键事实：项目中已经存在什么能力、模式、工具、约定。 - 后续 AI 必须知道的注意事项。 - 容易误改、重复造轮子或遗漏的点。 - 建议写入 `AGENTS.md` 的内容。 - 建议新增或更新的 `.agents/skills`，并说明触发场景。 - 未确认的信息和需要主 agent 二次核验的地方。 第三阶段：主 agent 汇总与去重 - 汇总所有 subagent 结果，去除重复、冲突和泛泛描述。 - 对冲突结论进行二次查证，以代码事实为准。 - 不要把所有内容堆进一个大 skill；按真实开发场景拆成小而明确的 skills。 - 如果已有 `.agents/skills` 或 `AGENTS.md`，必须在保留原有有效内容的基础上增量修改，不要粗暴覆盖。 - 如果某个 skill 只是通用工程建议，且没有项目特异性，不要创建。 第四阶段：补充 `.agents/skills` 为后续 AI 高频开发场景创建或更新项目专属 skill。每个 skill 应该包含： - 何时使用这个 skill。 - 该场景下必须先阅读的关键文件。 - 推荐执行流程。 - 常用命令。 - 项目内已有可复用模块、helper、组件或服务。 - 禁止事项或高风险误区。 - 验证方式。 优先考虑这些 skill 类型，但必须根据项目实际裁剪： - 本地开发与环境启动 skill。 - 测试、排障与质量验证 skill。 - 前端功能开发 skill。 - 后端/API 开发 skill。 - 数据模型/迁移 skill。 - 权限/认证相关 skill。 - 外部集成相关 skill。 - 发布/部署/CI 排障 skill。 - 项目架构导航 skill。 - 代码复用与避免重复实现 skill。 第五阶段：补充 `AGENTS.md` `AGENTS.md` 应该作为 AI 进入项目后的第一份上下文，内容应简洁、可执行、项目专属。至少包括： - 项目是什么，以及主要技术栈。 - 关键目录和模块职责。 - 本地启动、构建、测试、lint/typecheck 命令。 - 修改代码前应先阅读的文件。 - 核心架构约定和代码风格约定。 - 已有能力和复用入口，避免重复造轮子。 - 常见开发任务应该走哪些路径。 - 高风险区域和禁止随意改动的地方。 - 环境变量、外部依赖、生成文件、迁移文件等注意事项。 - 完成修改后的验证清单。 第六阶段：验证 完成写入后必须执行以下检查： - 确认新增或修改的 skill 文件路径正确、结构清晰、触发场景明确。 - 确认 `AGENTS.md` 不包含无法从项目中验证的臆测。 - 确认引用的命令、目录、文件名真实存在。 - 运行适合文档变更的轻量验证，例如查看 git diff、检查 Markdown 结构、必要时执行项目已有的 lint/test 命令。 - 最后输出总结：新增/更新了哪些 skills，`AGENTS.md` 补充了哪些内容，仍有哪些项目知识无法确认。 工作原则： - 并行优先：始终保持 subagent 满额运行，直到没有可独立推进的分析任务。 - 事实优先：所有项目说明必须能追溯到代码、配置、文档或测试。 - 场景优先：skills 面向后续 AI 的具体开发场景，而不是泛泛介绍。 - 增量优先：尊重已有文档和用户改动，不覆盖无关内容。 - 简洁优先：写对后续开发有用的内容，不制造冗长背景文档。 1 个帖子 - 1 位参与者 阅读完整话题
自用，刚刚炼化，适用于codex 所用模型为gpt5.5，发一贴的同时也希望对大家有帮助，用于帮你的导师 上级 同学 朋友 自己 通过codex把英文字幕弄进中文视频里面，假定了一个被称为快速模式的工作模型和相关流程 fast mode.zip (14.1 KB) 5 个帖子 - 5 位参与者 阅读完整话题
现在市面上的好像都是炼skill，但是这是远远做不到那种"日常"的聊天感觉的。 skill 本质上更像是把一个人的说话方式压缩成说明书，但是我想要的效果不是这样，我不想要简单的复刻一个聊天习惯，我想要复刻对方的整个"人"陪我接着聊天，接着发生活中的小事，接着聊一些日常什么的，并且延续下去。 大概想法是: 历史聊天记录先清洗切片后向量化存在本地向量数据库里,每次聊天时用当前输入去检索相似的历史片段，再把这些片段和长期风格画像一起塞给大模型生成回复。 并且在构想中新聊天也会继续进入数据库，成为之后检索的一部分。也就是说，它不是单纯回放过去，可以从过去延伸出新的聊天，可以真真切切的体会到对方曾经的行为，也可以从中延伸出未来。 在我发这篇帖子的时候，这个项目其实已经能跑了，效果挺好的，但是需要一些小优化什么的，我不确定要不要开源。 剧透 9 个帖子 - 7 位参与者 阅读完整话题
洗澡的时候突然想到，有没有一个工具能把我至今为止的微信，qq，浏览器，ai对话，备忘录，日记，工作记录等通通炼化，可以写成自传的那种，那样子别人也可以通过这些了解到我，也可以做成二维码刻慕悲上～ 5 个帖子 - 5 位参与者 阅读完整话题
一开始让我选我是干什么的还没啥感觉，说会根据选项和项目给我建议，还有点好奇会咋给我建议，第二个页面让我导入cc数据，感觉图穷匕见了 1 个帖子 - 1 位参与者 阅读完整话题
因为入站时候没有认真阅读规则,抽奖没有发原因(非必要不抽奖),有幸被俩次炼化成ldc–喜提禁言礼包.所以想用这篇帖子和大家聊一聊对于小违规被禁言后如何解禁. 如果你犯一些小错误比如抽奖贴因为没有看社区规则导致的被封禁,你可以给管理员进行私信承认错误,并且做出保证即可解禁.这个解禁速度还是很快的,当时解禁刚刚发了俩分钟私信就解开了. 进一步优化对抽奖帖回复被举报的处理方式 运营反馈 从 我发现我几乎所有的发言都被举报了，最近论坛内的言论有点风声鹤唳啊 继续讨论： [image] 虽然置顶公告和 社区准则 早就对举报异议做出了指引，但总有那不管不顾的非要跳出来直接发个帖子，大量占用公共资源。 我们可以把情况分为两种： 如果发帖人对举报异议不知情的，那么说明根本没看社区准则，可处理。 如果发帖人对举报异议知情的，那么说明他根本不在乎社区准则，可处理。 我这个人嘛，虽然在置顶… 1 个帖子 - 1 位参与者 阅读完整话题
今天吃饭突然想在服务器上搞个自部署 RSS，一年前用过很长一段时间 Folo，但是吃相越来越难看就卸载了，也没再折腾过 RSS 阅读器。最近发现 AI 知识又多又杂想搞一个聚合 + 定时的推送，吃饭摸鱼看看。于是通过 tg 机器人接 VPS 上的 Hermes 远程部署了 Miniflux + RSSHub，把 Anthropic 和 OpenAI 的博客塞了进去。当然因为学 AI 上 L 站，也塞了 L 站的热门榜 RSS。 在探索本站如何做 RSS 源时发现可以直接用/u/用户名/activity.rss 订阅用户动态， 诶，这不就可以视奸 。也是严肃对 Hermes 发了消息开始视奸 男朋友 ，全程都是吃夜宵过程中完成，agent 真好用嘻嘻。 被视奸者的反馈： 就是还是太受限于discourse底层架构了，只能视奸到未设置权限帖，要是可以通过接口什么的做属于自己的RSS源视奸到权限帖子就好了，这就是真正的顷刻炼化。 2 个帖子 - 2 位参与者 阅读完整话题