|
| 1 | +# 原则 |
| 2 | + |
| 3 | +## 1. 编码前思考 |
| 4 | + |
| 5 | +**不要假设。不要隐藏困惑。呈现权衡。** |
| 6 | + |
| 7 | +LLM 经常默默选择一种解释然后执行。这个原则强制明确推理: |
| 8 | + |
| 9 | +- **明确说明假设** — 如果不确定,询问而不是猜测 |
| 10 | +- **呈现多种解释** — 当存在歧义时,不要默默选择 |
| 11 | +- **适时提出异议** — 如果存在更简单的方法,说出来 |
| 12 | +- **困惑时停下来** — 指出不清楚的地方并要求澄清 |
| 13 | + |
| 14 | +## 2. 简洁优先 |
| 15 | + |
| 16 | +**用最少的代码解决问题。不要过度推测。** |
| 17 | + |
| 18 | +对抗过度工程的倾向: |
| 19 | + |
| 20 | +- 不要添加要求之外的功能 |
| 21 | +- 不要为一次性代码创建抽象 |
| 22 | +- 不要添加未要求的"灵活性"或"可配置性" |
| 23 | +- 不要为不可能发生的场景做错误处理 |
| 24 | +- 如果 200 行代码可以写成 50 行,重写它 |
| 25 | + |
| 26 | +**检验标准:** 资深工程师会觉得这过于复杂吗?如果是,简化。 |
| 27 | + |
| 28 | +## 3. 精准修改 |
| 29 | + |
| 30 | +**只碰必须碰的。只清理自己造成的混乱。** |
| 31 | + |
| 32 | +编辑现有代码时: |
| 33 | + |
| 34 | +- 不要"改进"相邻的代码、注释或格式 |
| 35 | +- 不要重构没坏的东西 |
| 36 | +- 匹配现有风格,即使你更倾向于不同的写法 |
| 37 | +- 如果注意到无关的死代码,提一下 —— 不要删除它 |
| 38 | + |
| 39 | +当你的改动产生孤儿代码时: |
| 40 | + |
| 41 | +- 删除因你的改动而变得无用的导入/变量/函数 |
| 42 | +- 不要删除预先存在的死代码,除非被要求 |
| 43 | + |
| 44 | +**检验标准:** 每一行修改都应该能直接追溯到用户的请求。 |
| 45 | + |
| 46 | +## 4. 目标驱动执行 |
| 47 | + |
| 48 | +**定义成功标准。循环验证直到达成。** |
| 49 | + |
| 50 | +将指令式任务转化为可验证的目标: |
| 51 | + |
| 52 | +| 不要这样做... | 转化为... | |
| 53 | +| ------------- | ------------------------------------ | |
| 54 | +| "添加验证" | "为无效输入编写测试,然后让它们通过" | |
| 55 | +| "修复 bug" | "编写重现 bug 的测试,然后让它通过" | |
| 56 | +| "重构 X" | "确保重构前后测试都能通过" | |
| 57 | + |
| 58 | +对于多步骤任务,说明一个简短的计划: |
| 59 | + |
| 60 | +``` |
| 61 | +1. [步骤] → 验证: [检查] |
| 62 | +2. [步骤] → 验证: [检查] |
| 63 | +3. [步骤] → 验证: [检查] |
| 64 | +``` |
| 65 | + |
| 66 | +强有力的成功标准让 LLM 能够独立循环执行。弱标准("让它工作")需要不断澄清。 |
| 67 | + |
| 68 | +# 命令 |
| 69 | + |
| 70 | +```bash |
| 71 | +pnpm i # 安装依赖 |
| 72 | +pnpm dev # 启动服务 |
| 73 | +pnpm build:staging # 打包构建预发布环境 |
| 74 | +pnpm build # 打包构建生产环境 |
| 75 | +pnpm preview # 先执行打包构建命令生成 dist 目录后再执行以下预览命令 |
| 76 | +pnpm lint # 代码校验与格式化 |
| 77 | +pnpm test # 单元测试 |
| 78 | +``` |
| 79 | + |
| 80 | +# 架构 |
| 81 | + |
| 82 | +## 技术栈 |
| 83 | + |
| 84 | +- 框架: Vue 3.5 |
| 85 | +- 打包构建工具: Vite 7 |
| 86 | +- 路由管理: Vue Router 4 |
| 87 | +- 状态管理: Pinia 3 |
| 88 | +- UI 组件库: Element Plus |
| 89 | +- CSS 预处理器: Scss |
| 90 | +- 代码校验与格式化: ESLint |
| 91 | +- 开发语言: TypeScript |
| 92 | +- 包管理工具: pnpm |
| 93 | +- 网络请求: Axios |
| 94 | + |
| 95 | +## 目录结构 |
| 96 | + |
| 97 | +```sh |
| 98 | +v3-admin-vite |
| 99 | +├─ .husky # commit 时进行代码校验和格式化 |
| 100 | +├─ .vscode # vscode 配置和插件 |
| 101 | +├─ public |
| 102 | +│ ├─ favicon.ico # 网站头像 |
| 103 | +│ ├─ app-loading.css # 首屏 loading 动画 |
| 104 | +│ └─ detect-ie.js # 检测 ie |
| 105 | +├─ src |
| 106 | +│ ├─ common # 通用目录 |
| 107 | +│ │ ├─ apis # 通用目录 - 接口 |
| 108 | +│ │ ├─ assets # 通用目录 - 静态资源 |
| 109 | +│ │ ├─ components # 通用目录 - 组件 |
| 110 | +│ │ ├─ composables # 通用目录 - 组合式函数 |
| 111 | +│ │ ├─ constants # 通用目录 - 常量 |
| 112 | +│ │ └─ utils # 通用目录 - 工具函数 |
| 113 | +│ ├─ http # 网络请求 |
| 114 | +│ ├─ layouts # 布局 |
| 115 | +│ ├─ pages # 页面 |
| 116 | +│ │ └─ login # 登录模块 |
| 117 | +│ │ ├─ apis # 登录模块 - 私有接口 |
| 118 | +│ │ ├─ components # 登录模块 - 私有组件 |
| 119 | +│ │ ├─ composables # 登录模块 - 私有组合式函数 |
| 120 | +│ │ ├─ images # 登录模块 - 私有图片 |
| 121 | +│ │ └─ index.vue # 登录模块 - 页面 |
| 122 | +│ ├─ pinia # 状态管理 |
| 123 | +│ ├─ plugins # 插件(全局组件、自定义指令等) |
| 124 | +│ ├─ router # 路由 |
| 125 | +│ ├─ App.vue # 入口页面 |
| 126 | +│ └─ main.ts # 入口文件 |
| 127 | +├─ tests # 单元测试 |
| 128 | +├─ types # 类型声明 |
| 129 | +│ └─ auto # 自动生成的类型 |
| 130 | +├─ .editorconfig # 编辑器配置 |
| 131 | +├─ .env # 所有环境 |
| 132 | +├─ .env.development # 开发环境 |
| 133 | +├─ .env.production # 生产环境 |
| 134 | +├─ .env.staging # 预发布环境 |
| 135 | +├─ eslint.config.js # eslint 配置 |
| 136 | +├─ tsconfig.json # ts 配置 |
| 137 | +├─ uno.config.ts # unocss 配置 |
| 138 | +└─ vite.config.ts # vite 配置 |
| 139 | +``` |
| 140 | + |
| 141 | +- 保持目录结构清晰,遵循现有目录规范 |
| 142 | +- 同一个业务逻辑的代码和资源应当被收拢到了一起,避免在不同的目录间来回跳跃 (例如登录模块的接口应该放在 `src/pages/login/apis` 而不是 `src/common/apis`) |
| 143 | + |
| 144 | +# 约定 |
| 145 | + |
| 146 | +参考 `.cursor/rules` 规则 |
0 commit comments