我的 id 是 464 ，来自 xproxy.ai

不试试 VoxCPM ？

试试 233boy ？

@BaiLinfeng 也不是说专门学过，就每天刷各种论坛。反正我了解的就是一条线：Prompt Engineering => Context Engineering => Harness Engineering （现在主流）。然后 claude code 源码泄露过，网上各种解析，用源码推如何写提示词+如何 Harness 。大致就是这样。

进入工程文件夹，启动 claude code | codex ，先/init 。然后开始改 CLAUDE.md|AGENTS.md 。
改为类似
`
# Ben Admin Template - Claude Code Gateway

> 长期红线与稳定偏好由 Memory 负责，当前项目规则由 `.claude/rules/*` 负责。

## Highest Priority Guardrails

- Never run `rm` or `rm -rf`.
- Never modify Git state unless the user explicitly asks, including `git add`, `git commit`, `git push`, `git reset`, and `git checkout`.
- Before shell commands, check Memory `critical_rules.md`.
- Do not claim completion, fixed, or passing without fresh verification evidence.
- Ask before any irreversible or high-risk action.

## Project Rules

@.claude/rules/coding-standards.md
@.claude/rules/project-context.md
@.claude/rules/collaboration-contract.md
@.claude/rules/workflow-triggers.md

## Skills

- Prefer project skills over user/global skills.
- Matt skills are on-demand capabilities; they do not replace project rules.
- Use `planning-with-files` only for long-lived, cross-session, or explicitly requested planning work.
- Run `linus-review` before delivery when `.claude/rules/workflow-triggers.md` says it is required.

## Local Constraints

- `.claude/rules/` owns project collaboration, coding standards, project context, and workflow triggers.
- When deeper local `*.md` files exist, read their local constraints first and apply them without violating higher-priority guardrails.

## Agent skills

### Issue tracker

Issues and PRDs live as local markdown files in `.scratch/`. See `docs/agents/issue-tracker.md`.

### Triage labels

Uses the default five-role vocabulary: needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix. See `docs/agents/triage-labels.md`.

### Domain docs

Single-context layout — one `CONTEXT.md` + `docs/adr/` at the repo root. See `docs/agents/domain.md`.

`
再加上一些对应语言的 skills

CRUD 前端一枚。虽然 5.5 和 4.6/7 确实屌，但是 glm5.1 对我已经基本足够。所以需求层面差不多建议 ollama pro 爽蹬。

我 3 天前领的 10 刀，还没用，刚才看了下回收了？

Y3hAY3hzcmJxLmNjd3UuY2M=
谢谢老板

HONGMACC-67B8B41F
祝老板发财

ID: 312
祝老板发财

c3VueDEzMjUxQGdtYWlsLmNvbQ==
谢谢老板

@yicong135 我是项目根目录下的 CLAUDE.md 里指向了此文件

用 @符号指向
@.claude/rules/workflow-superpowers.md
.claude/ 存在于项目根目录

我是建了个 rule ，workflow-superpowers.md 目前感觉还行。根据任务大小自动启动路径
内容如下
`
# 工作流路由

## 1. 任务分流

### Fast Path

适用于：

- 单文件修改
- 明确 bug
- 小范围配置调整
- 边界清晰的文案或规则修订
- 可直接完成并做定向验证的小改动

要求：

- 直接执行
- 约束（不可跳过）：任何 Bash 调用前，必须依据 Memory 中 `critical_rules` 逐条校验即将执行的命令。
如果命令包含被禁操作（如 `rm`、`rm -rf`、修改 Git 状态的命令），必须：
1. 改用替代方案（删除 → `mv` 至回收站 `~/.aicode.tmp/{yyyy-MM-dd}/{HH:mm}/`）
2. 如无可用替代方案，向用户报告冲突，请求指示
3. 不得在未解决冲突的情况下继续当前路径
- 做定向验证
- 默认采用满足质量要求的最短路径
- 最多只问一个真正关键的问题
- 若现有上下文已足够，就不要重复提问

### Standard Path

适用于：

- 多文件修改
- 边界基本清晰，但需要先梳理现状
- 需要对现有结构做局部调整
- 中等复杂度实现，仍可用短路径收敛

要求：

- 先梳理上下文
- 明确改动边界、风险和验证方式
- 分步执行并持续验证
- 优先使用轻量已安装的 `planning-with-files` skill ，而不是先产出重文档
- 根据任务进行情况，维护`planning-with-files` skill 衍生的规划文件，衍生的规划文件里最新产出倒序新增

### Heavy Path

适用于：

- 新功能
- 跨模块重构
- 公共 API 变更
- 三步以上的复杂任务
- 高不确定性或高破坏性任务
- 涉及共享逻辑、持久化、并发、schema 或根配置的改动

要求：

- 进入更重的规划流程
- 先设计，再实施
- 必要时拆分阶段产物和确认点
- 在实现前明确验证门禁和回退边界
- 启动 superpowers`writing-plans`产出 plan,进度与发现维护在`planning-with-files` skill 衍生的规划文件，衍生的规划文件里最新产出倒序新增

## 2. 使用 superpowers 的原则

- superpowers 是工具，不是默认仪式
- 默认采用“满足质量要求的最短路径”
- 能直接完成并验证的，不升级为更重流程
- 能用轻量 `planning-with-files` 解决的问题，不升级为重文档流程
- 轻量任务默认不产出独立 design / spec / plan ，除非用户明确要求、项目规则要求，或确有长期协作价值
- 若用户要求持续推进且风险可控，可在说明假设后继续，不因无谓确认中断

## 3. 流程升级 / 降级

### 升级到更重流程

出现下列情况时，应从 Fast Path / Standard Path 升级：

- 影响边界超出初始判断
- 涉及公共 API 、shared contract 、shared types 、schema 、持久化、并发或共享逻辑
- 需求仍不清晰，无法靠现有上下文收敛
- 验证覆盖不足，无法支持完成声明
- 任务已演变为中大型实现或重构

### 降级到更轻流程

出现下列情况时，可从 Heavy Path / Standard Path 降级：

- 改动局部且边界清晰
- 不涉及共享核心逻辑
- 验证直接、成本低
- 补长计划或补重流程的成本明显高于收益
- 问题已经收敛为单点修复

## 4. 并行与子代理

- 默认先判断是否适合并行；不适合则串行
- 只有在任务能自然拆分为 2-4 个边界清晰、可独立验证、没有明显写冲突的子任务时，才适合并行
- 若根因未明、改动集中在少数核心文件，或拆分后整合成本更高，则不要为了并行而并行

**禁止多个子代理同时修改：**

- `package.json`
- lockfile
- 公共 contract / shared types
- schema / migration
- 全局依赖
- 根配置
- CI
- 同一路由总入口
- 应用总入口
- 环境模板

## 5. 交付门禁

在声明“完成”之前，必须满足：

1. 没有验证证据时，不声称完成
2. 不伪造命令输出、测试结果或退出码
3. 关键验证无法执行时，明确说明阻塞原因
4. 需要用户承担风险的动作，先确认再做
5. 若验证不足，只能降低完成度表述，不能把“未验证”说成“已完成”
6. 能做局部验证时，先给出最贴近本次改动的验证结果
7. 任何涉及 2 个或以上文件的改动，或在 `constants.ts`、`composables`、`types/` 目录中新增/修改，必须在交付前对照 `persona-linus.md` 的审查顺序自查
8. [品味自评核验] （不可跳过）
如果本次改动触及第 7 条的范围，必须检查对话末尾是否已输出 [品味自评] 结论。
如果没有，在交付前补充输出。这条检查的是"规则是否被执行了"，而不是"规则是否存在"。

`

@happytaoer 你链接 ide ，它改动完会直接弹出 diff ，供你选择留或者取消的啊。

刚好相反，不够苦不够浓的话完全喝不下去。某迪的金奖深烘加浓美式 YYDS 。

😆哈哈哈哈哈，笑死了

DOTA2