开发工具CLIOpenHarmonyMCP 服务移动开发【免费下载链接】deveco-cli集成HarmonyOS应用开发工具集提供知识文档和精品Skills支持多种智能体助力开发者使用AI辅助高效开发HarmonyOS应用。项目地址https://gitcode.com/openharmony-sig/deveco-cli点击查看免费下载deveco-cliHarmonyOS 应用开发命令行工具在仓库内为 AI 编码助手沉淀了一套标准化的代码变更/MR 审查工作流本指南以 .agents/skills/deveco-code-review/SKILL.md 为核心结合仓库源码与配套 Skill 展开讲解。读完本文你将掌握在 deveco-cli 仓库中审查 CLI 与 MCP 变更时需要执行的完整检查清单——包括接口行为、职责归属、进程生命周期、边界安全、真实入口验证与回归证据的收集方法并理解每一条规则背后的源码依据。一、审查 Skill 在仓库开发工作流中的定位deveco-cli 是一个 npm workspace 仓库包含 4 个包cli发布为deveco/deveco-cli、docs-engine私有搜索/读取运行时、docs-index-builder私有索引构建、docs-zh发布为deveco/deveco-cli-knowledgebase。仓库的常设规则conventions、领域模块范式、环境变量、架构说明统一沉淀在根目录 AGENTS.md 中而开发工作流则按任务拆分为.agents/skills/下的多个 Skill任务工作流审查代码变更或合并请求deveco-code-review本文核心提交/推送前选择最小可信检查集deveco-check-changes编写或诊断涉及子进程/锁/取消/时序/共享状态的测试deveco-test-reliability重构或审计重复规则与简化候选deveco-find-simplifications编写或审查文档、注释、诊断信息deveco-docs-and-prose从源码结构看这套 Skill 体系与根 AGENTS.md 的分工是明确的根 AGENTS.md 拥有常设仓库规则各开发 Skill 只负责各自的工作流步骤。审查 Skill 的适用场景集中在四个方面CLI 与 MCP 消费者谁在调用命令与协议、共享解析逻辑JSON5 配置解析等、外部进程生命周期ohpm/hvigor/hdc/emulator 子进程、以及回归证据测试能否真实捕获原始缺陷。一个贯穿全文的核心原则是发现结论必须基于当前代码、测试和实际运行的命令作者或 Agent 的口头描述不构成证据。二、审查前准备Before reviewing审查 Skill 要求在执行任何检查前完成三项准备工作1. 确认审查基线。必须先确认 base 提交、target 提交与 worktree 状态读取完整 diff 以及足够的上下文当基线变更amend、rebase、换 base或 retarget 之后必须重新核对 diff避免基于过时内容下结论。2. 阅读配套 Skill。每次审查都应先读 deveco-check-changes 来选择最小可信检查集当变更涉及异步资源子进程、锁、取消、MCP 初始化、共享状态时还必须读 deveco-test-reliability当变更涉及文档或用户可见文本时读 deveco-docs-and-prose。3. 明确变更要素。识别具体的输入、预期结果、失败行为、变更范围与真实入口点。范围之外发现的问题应单独记录而不是塞进当前修复里——这保证了 diff 的聚焦性与 AGENTS.md 中渐进迁移、一次一触、不让 diff 超出变更所需的原则一致。三、必查清单Required checks逐项拆解3.1 接口与行为双向追踪每一个变更接口对每个被修改的接口必须同时追踪接口两侧定义方与消费方以及所有生产调用者逐一核对参数、返回值、默认值错误类型与错误信息退出码、stdout/stderr 输出兼容性行为新老版本切换时的表现。这条规则的仓库背景是deveco-cli 的 CLI 与 MCP 是两套对外契约。CLI 侧packages/cli/src/cli.ts 通过 commander 注册build/run/update/device/emulator/auth/skills/log/create/init/serve/doc/ui/check/signature/verify全部子命令命令参数、flag 与输出格式都是用户可见行为MCP 侧packages/cli/mcp/src-server/通过modelcontextprotocol/sdk暴露check等工具工具名、输入 schema、返回文本都是协议级契约。审查时任何一侧的改动都要顺藤摸瓜到另一侧。3.2 职责与重复每条共享规则只有一个 ownerSkill 明确要求每条共享规则只能有一个属主owner。仓库内的两个典型所有权归属是ToolProvider 拥有工具链路径Studio/CLT 发现与ohpm/hvigor/hdc/emulator/bundled node 等组件路径的解析集中在 packages/cli/src/toolchain/tool-provider.tsCLI 与 MCP 都消费它而不应各自实现安装布局探测既有解析器拥有项目 JSON5HarmonyOS 配置build-profile.json5、module.json5、oh-package.json5、app.json5的统一解析由既有 parser 承担AGENTS.md 还特别强调这些文件要用json5解析而非原生JSON.parse。命令层则应保持编排与渲染的单一职责不得复制安装布局、配置优先级或业务规则。这与 AGENTS.md 的领域模块范式一脉相承src/domain/index.ts是唯一 barrel能力内部按types.ts → 纯函数 → adapter三层拆分adapter 是唯一做 IO 的层命令保持瘦身Options 接口 commander option 链 handle*异步函数spinner → 调 adapter → 格式化输出。3.3 生命周期与并发信号要追踪到最终进程对于锁、取消、超时、watch、重启或子进程相关变更审查必须把信号追踪到最终进程验证退出与锁释放是否可靠监听器是否正确移除旧任务完成后进程处于什么状态错误是否独立上报、互不干扰。仓库中有大量此类场景可作参照devecocli run --hotreload会作为后台进程持有到 hvigor daemon 的持久 socket需要显式 killMCP 服务器在 packages/cli/mcp/src-server/server.ts 中维护 ArkTS 与 C 两套独立生命周期状态机IDLE → DISCOVERING → SYNCING → INITIALIZING → READY/ERROR并设有MAX_INIT_RETRY 3、SYNC_SKIP_TIMEOUT_MS与MAX_CHECK_FILES 100等边界常量。审查涉及生命周期变更时应检查这些状态机是否存在新路径绕开就绪/错误处理。3.4 边界与安全拒绝路径与替代调用者都不能绕过约束审查要在文件、JSON5、网络、外部命令与 MCP 协议五类边界上检查解析、路径、cwd、环境变量、argv、超时与失败传播路径类输入是否有 containment 校验仓库已有 packages/cli/src/utils/path-containment.ts 实现resolveCanonicalPath/resolvePathInsideRoot从 JSON5、CLI argv、设备输出、文件、网络、协议进入的数据必须与同进程内已被 TypeScript 保证的值区分对待不得盲目删除防御性校验验证既不存在拒绝路径denial path也没有替代调用者能绕过约束——即约束必须在真实入口生效而不只是某一条调用链上生效。3.5 真实入口验证Handler 单测不等于发布入口可用这是审查 Skill 强调得最重的一条CLI 变更必须通过构建产物packages/cli/dist/cli.js验证用户可见行为。src/下的编辑在npm run buildtsup 打包为单个 minified ESM bundlebin 为devecocli之前不会进入产物因此成功编译不等于用户入口可用MCP 变更必须通过真实的devecocli serve mcp入口或等价的打包协议路径验证。packages/cli/src/commands/serve.ts中的startStdioMcpServer从ToolProvider一次性解析 sdk/arkts-lsp/node/ohpm/hvigor/clangd 路径后调用createMcpServer接管 stdin/stdout 作为 stdio 通信通道并注册 SIGINT/SIGTERM/SIGBREAK 关闭信号仅做 handler 级别的单元测试不足以证明这个打包后的入口真正可用。同理devecocli serve lsp--arkts走 ace-server、--cpp走 clangd是长期运行的 stdio 服务器审查此类变更时应关注--project-path/--auto-detect的解析语义而不是把它当作一次性 shell 命令验证。3.6 回归证据测试要观察外部行为并为原始缺陷失败回归测试必须满足两个硬条件观察外部行为——例如包名、工具 argv、文件结果、状态转换或协议响应而不是函数被调用成功提示这类内部信号为原始缺陷失败——用旧的有缺陷实现或定向负向对照证明该测试确实能捕获回归。同时要确认当前配置能够发现这些测试vitest 的 include 配置在 vitest.config.ts 中为packages/*/src/**/*.test.ts与packages/cli/mcp/src-server/**/*.test.tseslint 在 eslint.config.js 中覆盖packages/*/src/**/*.ts与.plugin的 TS/MJS且对生产代码强制max-lines-per-function: 50、max-depth: 4。若测试发现配置变更应先用一个临时失败用例证明 runner 会执行并报告失败再移除该用例。检查集的选择交给 deveco-check-changes——它按 diff 影响面路由禁止因为提交了就重复跑全量检查。3.7 测试可靠性私有资源、真实同步点、完整清理涉及测试的审查要核对每个测试使用私有临时目录显式设置子进程 cwd 与所需环境变量避免读取用户真实项目、凭据或默认数据目录使用listen(0)读取系统分配的地址文件/数据库/socket/输出路径使用唯一名称或排他创建禁止先扫描可用性再认领资源用真实同步点就绪信号、ack、受控阻塞替代固定 sleep 等待超时只用于界定失败等待不能用于证明同步用try/finally围绕最小变更范围恢复共享可变状态process.env、cwd、timers、locale、全局 mock、fetch 拦截区分启动前取消执行中取消正常非零退出锁测试要观察到后续任务真正获取到锁超时/失败后终止测试拥有的进程并等待进程、监听器、异步任务全部停止再删除临时目录——kill()/release()调用本身不证明清理完成Windows 与 POSIX 在环境变量大小写、文件句柄释放、信号、权限上存在差异优先选择跨平台成立的观察方式需要 Studio/CLT/设备的测试要分别列出前置条件与平台单机通过不构成跨平台覆盖。3.8 文档同步同一 diff 内更新 README、SKILL.md 与 JSDoc命令、flag、错误、发布资源或公开行为发生变更时必须在同一个 diff内同步更新面向用户/Agent 的调用指南 SKILL.md 与 README.md命令名、默认值、互斥条件、失败条件、平台能力公开 JSDoc返回值区别、异常、变更、所有权、时序、取消、持久化承诺模块/内部注释职责、竞态、资源所有权、安全边界、兼容性承诺。这是契约归属其位原则命令指南的契约属于产品 Skill 与 README代码内部契约属于注释测试注释只解释非显然的 fixture、平台迁就、真实入口路径与间接观察理由。3.9 设计质量新抽象必须有生产调用者审查设计质量时重点检查新抽象是否已有当前生产调用者是否减少了需要手工保持同步的规则而不是新增分支是否存在硬编码的可变配置、无证据的默认值、重复的防御逻辑是否存在与任务无关的扩展speculative generality为想象中的未来预留接口。这条规则在 deveco-find-simplifications 中有更完整的展开没有生产消费者的 symbol/参数/配置/事件/缓存/测试产物、两处维护同一业务事实的实现、仅为测试或示例服务的抽象都是强简化候选但零引用本身不构成删除理由——外部脚本可能依赖 CLI 参数、输出与文件格式必须核实外部消费者。四、报告发现Report findings的规范审查报告的每条缺陷必须包含四要素位置、触发条件、影响、证据。优先级排序为错误行为 数据损坏 资源泄漏 兼容性回归 无效的质量检查。同时遵守建议与阻塞分离建议suggestion与阻塞blocker分开陈述不要混为一谈验证缺口显式标注未运行的路径要标记为 validation gap不能用应该没问题替代不重复已覆盖的发现已被通过的自动化检查覆盖的问题不再列出权限边界一次审查任务本身不授权代码编辑、发布审查评论或合并请求。五、配套 Skill 协作全景四个 Skill 如何支撑一次完整审查deveco-code-review 不是孤立的它与其余四个开发 Skill 形成闭环deveco-check-changes选择检查集负责在提交/推送/报告验证结果前从实际 diff 建立基线并路由证据TypeScript 实现/类型走npm run lintnpm test -- 相关路径不在自动覆盖内或涉及 CLI 注册/输出/入口/发布资源的代码要npm run build后经真实入口验证CI/依赖/package 脚本按受影响范围跑lint/test/build纯文案变更只需git diff --check 手工核对元数据与本地引用。它还强调超时、跳过、未运行的检查都不是通过fake hdc/hvigor/ohpm 测试不能建立与真实 Studio 安装、CLT 或设备的兼容性本地通过也不等于 GitCode pipeline 或分支保护已验证。deveco-test-reliability测试可靠性提供隔离、同步、取消、清理的完整决策框架见 3.7并明确在安静的机器上单机通过不足以证明可重复性。deveco-docs-and-prose文档与散文要求先识别文段中的每一个命题actor、动作、条件、时序、must/may/never 模态、异常、所有权、副作用、失败模式、后果再决定保留/增删/重构编辑前需对照当前代码、help 输出与实际运行验证事实验证命令名、相对 Markdown 链接与代码-文档一致性后运行git diff --check。deveco-find-simplifications简化候选在审查之外提供把表象复杂度转化为可评审的简化候选的方法论先用rg搜索精确符号/命令名/配置键/方法名/线串/动态加载入口再读调用者、公共接口、测试、README、脚本与配置将消费者分类为生产代码/测试文档/角色不确定的示例脚本。六、实战演练一次典型变更的审查路径以修改某个 CLI 子命令的 flag 与输出格式为例把上述规则串成一条可执行路径确认基线记录 base 与 target commit、worktree 状态读取完整 diff路由检查按 deveco-check-changes 的表格该变更落在CLI 注册、输出、入口行——先跑npm run lint再npm run build然后用构建产物packages/cli/dist/cli.js实际执行该子命令验证 flag、默认值、退出码与 stdout/stderr回归证据确认相关测试观察外部行为输出文本、退出码而非内部函数调用且对原始缺陷会失败用 vitest.config.ts 的 include 范围确认测试会被发现文档同步在同一 diff 内更新 SKILL.md 与 README.md 中对应命令/flag 的说明必要时更新 JSDoc生命周期检查若变更涉及子进程或锁如run --apply、--hotreload、MCP 重启按 3.3 追踪信号到最终进程并核对清理路径输出报告按位置、触发、影响、证据逐条列出建议与阻塞分开未运行路径标为验证缺口。七、审查底线与常见误区最后重申几条不容妥协的底线它们也是本 Skill 与 AGENTS.md 反复强调的口头描述不是证据结论必须能落到当前代码、测试或实际运行的命令上静默通过不是通过超时、跳过、未运行的检查都不能算验证通过检查失败必须停下修复或明确声明阻塞构建成功不等于入口可用npm run build只证明能编译用户入口必须通过构建产物真实执行验证fake 工具测试不等于真实兼容mock hdc/hvigor/ohpm 的测试不能证明与真实 Studio 安装、CLT 或设备的兼容性本地通过不等于远端验证本地测试通过不能证明 GitCode pipeline 或分支保护已验证推送/重写历史需要用户授权审查不等于修改授权一次代码审查任务不授权编辑代码、发布审查评论或合并请求。遵循以上流程开发者与 AI 编码助手即可在 deveco-cli 仓库中产出证据充分、范围聚焦、可被复核的代码审查结论为 CLI 与 MCP 这两条对外契约线守住质量底线。赞分享开发工具CLIOpenHarmonyMCP 服务移动开发【免费下载链接】deveco-cli集成HarmonyOS应用开发工具集提供知识文档和精品Skills支持多种智能体助力开发者使用AI辅助高效开发HarmonyOS应用。项目地址https://gitcode.com/openharmony-sig/deveco-cli点击查看免费下载相关推荐代码审查清单Android-PickerView代码审查清单Android PickerView 架构模块依赖符合设计无循环依赖 功能核心场景时间选择、联动选择测试通过 性能 WheelVie移动开发UI组件终极JavaScript代码审查清单团队协作的完整规范流程指南终极JavaScript代码审查清单团队协作的完整规范流程指南 在现代软件开发中保持代码质量和一致性是团队协作的核心挑战。GitHub加速计划下的idiomatomcode 的 Erlang 代码审查规则面向自动化评审员的六类检查清单与源码级原理atomcode 的 Erlang 代码审查规则面向自动化评审员的六类检查清单与源码级原理 atomcode 是 Rust 构建的开源 AI 编程助手其 a人工智能AI 应用AI Agent代码智能体CLIAI 评测上一篇开源项目Sushi概览与新手指南下一篇OpenUpgrade 项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/16 1:39:18 · 阅读 1.2k deveco-cli 代码审查指南：面向 CLI/MCP 变更的审查流程与源码级检查清单
开发工具CLIOpenHarmonyMCP 服务移动开发【免费下载链接】deveco-cli集成HarmonyOS应用开发工具集提供知识文档和精品Skills支持多种智能体助力开发者使用AI辅助高效开发HarmonyOS应用。项目地址https://gitcode.com/openharmony-sig/deveco-cli点击查看免费下载deveco-cliHarmonyOS 应用开发命令行工具在仓库内为 AI 编码助手沉淀了一套标准化的代码变更/MR 审查工作流本指南以 .agents/skills/deveco-code-review/SKILL.md 为核心结合仓库源码与配套 Skill 展开讲解。读完本文你将掌握在 deveco-cli 仓库中审查 CLI 与 MCP 变更时需要执行的完整检查清单——包括接口行为、职责归属、进程生命周期、边界安全、真实入口验证与回归证据的收集方法并理解每一条规则背后的源码依据。一、审查 Skill 在仓库开发工作流中的定位deveco-cli 是一个 npm workspace 仓库包含 4 个包cli发布为deveco/deveco-cli、docs-engine私有搜索/读取运行时、docs-index-builder私有索引构建、docs-zh发布为deveco/deveco-cli-knowledgebase。仓库的常设规则conventions、领域模块范式、环境变量、架构说明统一沉淀在根目录 AGENTS.md 中而开发工作流则按任务拆分为.agents/skills/下的多个 Skill任务工作流审查代码变更或合并请求deveco-code-review本文核心提交/推送前选择最小可信检查集deveco-check-changes编写或诊断涉及子进程/锁/取消/时序/共享状态的测试deveco-test-reliability重构或审计重复规则与简化候选deveco-find-simplifications编写或审查文档、注释、诊断信息deveco-docs-and-prose从源码结构看这套 Skill 体系与根 AGENTS.md 的分工是明确的根 AGENTS.md 拥有常设仓库规则各开发 Skill 只负责各自的工作流步骤。审查 Skill 的适用场景集中在四个方面CLI 与 MCP 消费者谁在调用命令与协议、共享解析逻辑JSON5 配置解析等、外部进程生命周期ohpm/hvigor/hdc/emulator 子进程、以及回归证据测试能否真实捕获原始缺陷。一个贯穿全文的核心原则是发现结论必须基于当前代码、测试和实际运行的命令作者或 Agent 的口头描述不构成证据。二、审查前准备Before reviewing审查 Skill 要求在执行任何检查前完成三项准备工作1. 确认审查基线。必须先确认 base 提交、target 提交与 worktree 状态读取完整 diff 以及足够的上下文当基线变更amend、rebase、换 base或 retarget 之后必须重新核对 diff避免基于过时内容下结论。2. 阅读配套 Skill。每次审查都应先读 deveco-check-changes 来选择最小可信检查集当变更涉及异步资源子进程、锁、取消、MCP 初始化、共享状态时还必须读 deveco-test-reliability当变更涉及文档或用户可见文本时读 deveco-docs-and-prose。3. 明确变更要素。识别具体的输入、预期结果、失败行为、变更范围与真实入口点。范围之外发现的问题应单独记录而不是塞进当前修复里——这保证了 diff 的聚焦性与 AGENTS.md 中渐进迁移、一次一触、不让 diff 超出变更所需的原则一致。三、必查清单Required checks逐项拆解3.1 接口与行为双向追踪每一个变更接口对每个被修改的接口必须同时追踪接口两侧定义方与消费方以及所有生产调用者逐一核对参数、返回值、默认值错误类型与错误信息退出码、stdout/stderr 输出兼容性行为新老版本切换时的表现。这条规则的仓库背景是deveco-cli 的 CLI 与 MCP 是两套对外契约。CLI 侧packages/cli/src/cli.ts 通过 commander 注册build/run/update/device/emulator/auth/skills/log/create/init/serve/doc/ui/check/signature/verify全部子命令命令参数、flag 与输出格式都是用户可见行为MCP 侧packages/cli/mcp/src-server/通过modelcontextprotocol/sdk暴露check等工具工具名、输入 schema、返回文本都是协议级契约。审查时任何一侧的改动都要顺藤摸瓜到另一侧。3.2 职责与重复每条共享规则只有一个 ownerSkill 明确要求每条共享规则只能有一个属主owner。仓库内的两个典型所有权归属是ToolProvider 拥有工具链路径Studio/CLT 发现与ohpm/hvigor/hdc/emulator/bundled node 等组件路径的解析集中在 packages/cli/src/toolchain/tool-provider.tsCLI 与 MCP 都消费它而不应各自实现安装布局探测既有解析器拥有项目 JSON5HarmonyOS 配置build-profile.json5、module.json5、oh-package.json5、app.json5的统一解析由既有 parser 承担AGENTS.md 还特别强调这些文件要用json5解析而非原生JSON.parse。命令层则应保持编排与渲染的单一职责不得复制安装布局、配置优先级或业务规则。这与 AGENTS.md 的领域模块范式一脉相承src/domain/index.ts是唯一 barrel能力内部按types.ts → 纯函数 → adapter三层拆分adapter 是唯一做 IO 的层命令保持瘦身Options 接口 commander option 链 handle*异步函数spinner → 调 adapter → 格式化输出。3.3 生命周期与并发信号要追踪到最终进程对于锁、取消、超时、watch、重启或子进程相关变更审查必须把信号追踪到最终进程验证退出与锁释放是否可靠监听器是否正确移除旧任务完成后进程处于什么状态错误是否独立上报、互不干扰。仓库中有大量此类场景可作参照devecocli run --hotreload会作为后台进程持有到 hvigor daemon 的持久 socket需要显式 killMCP 服务器在 packages/cli/mcp/src-server/server.ts 中维护 ArkTS 与 C 两套独立生命周期状态机IDLE → DISCOVERING → SYNCING → INITIALIZING → READY/ERROR并设有MAX_INIT_RETRY 3、SYNC_SKIP_TIMEOUT_MS与MAX_CHECK_FILES 100等边界常量。审查涉及生命周期变更时应检查这些状态机是否存在新路径绕开就绪/错误处理。3.4 边界与安全拒绝路径与替代调用者都不能绕过约束审查要在文件、JSON5、网络、外部命令与 MCP 协议五类边界上检查解析、路径、cwd、环境变量、argv、超时与失败传播路径类输入是否有 containment 校验仓库已有 packages/cli/src/utils/path-containment.ts 实现resolveCanonicalPath/resolvePathInsideRoot从 JSON5、CLI argv、设备输出、文件、网络、协议进入的数据必须与同进程内已被 TypeScript 保证的值区分对待不得盲目删除防御性校验验证既不存在拒绝路径denial path也没有替代调用者能绕过约束——即约束必须在真实入口生效而不只是某一条调用链上生效。3.5 真实入口验证Handler 单测不等于发布入口可用这是审查 Skill 强调得最重的一条CLI 变更必须通过构建产物packages/cli/dist/cli.js验证用户可见行为。src/下的编辑在npm run buildtsup 打包为单个 minified ESM bundlebin 为devecocli之前不会进入产物因此成功编译不等于用户入口可用MCP 变更必须通过真实的devecocli serve mcp入口或等价的打包协议路径验证。packages/cli/src/commands/serve.ts中的startStdioMcpServer从ToolProvider一次性解析 sdk/arkts-lsp/node/ohpm/hvigor/clangd 路径后调用createMcpServer接管 stdin/stdout 作为 stdio 通信通道并注册 SIGINT/SIGTERM/SIGBREAK 关闭信号仅做 handler 级别的单元测试不足以证明这个打包后的入口真正可用。同理devecocli serve lsp--arkts走 ace-server、--cpp走 clangd是长期运行的 stdio 服务器审查此类变更时应关注--project-path/--auto-detect的解析语义而不是把它当作一次性 shell 命令验证。3.6 回归证据测试要观察外部行为并为原始缺陷失败回归测试必须满足两个硬条件观察外部行为——例如包名、工具 argv、文件结果、状态转换或协议响应而不是函数被调用成功提示这类内部信号为原始缺陷失败——用旧的有缺陷实现或定向负向对照证明该测试确实能捕获回归。同时要确认当前配置能够发现这些测试vitest 的 include 配置在 vitest.config.ts 中为packages/*/src/**/*.test.ts与packages/cli/mcp/src-server/**/*.test.tseslint 在 eslint.config.js 中覆盖packages/*/src/**/*.ts与.plugin的 TS/MJS且对生产代码强制max-lines-per-function: 50、max-depth: 4。若测试发现配置变更应先用一个临时失败用例证明 runner 会执行并报告失败再移除该用例。检查集的选择交给 deveco-check-changes——它按 diff 影响面路由禁止因为提交了就重复跑全量检查。3.7 测试可靠性私有资源、真实同步点、完整清理涉及测试的审查要核对每个测试使用私有临时目录显式设置子进程 cwd 与所需环境变量避免读取用户真实项目、凭据或默认数据目录使用listen(0)读取系统分配的地址文件/数据库/socket/输出路径使用唯一名称或排他创建禁止先扫描可用性再认领资源用真实同步点就绪信号、ack、受控阻塞替代固定 sleep 等待超时只用于界定失败等待不能用于证明同步用try/finally围绕最小变更范围恢复共享可变状态process.env、cwd、timers、locale、全局 mock、fetch 拦截区分启动前取消执行中取消正常非零退出锁测试要观察到后续任务真正获取到锁超时/失败后终止测试拥有的进程并等待进程、监听器、异步任务全部停止再删除临时目录——kill()/release()调用本身不证明清理完成Windows 与 POSIX 在环境变量大小写、文件句柄释放、信号、权限上存在差异优先选择跨平台成立的观察方式需要 Studio/CLT/设备的测试要分别列出前置条件与平台单机通过不构成跨平台覆盖。3.8 文档同步同一 diff 内更新 README、SKILL.md 与 JSDoc命令、flag、错误、发布资源或公开行为发生变更时必须在同一个 diff内同步更新面向用户/Agent 的调用指南 SKILL.md 与 README.md命令名、默认值、互斥条件、失败条件、平台能力公开 JSDoc返回值区别、异常、变更、所有权、时序、取消、持久化承诺模块/内部注释职责、竞态、资源所有权、安全边界、兼容性承诺。这是契约归属其位原则命令指南的契约属于产品 Skill 与 README代码内部契约属于注释测试注释只解释非显然的 fixture、平台迁就、真实入口路径与间接观察理由。3.9 设计质量新抽象必须有生产调用者审查设计质量时重点检查新抽象是否已有当前生产调用者是否减少了需要手工保持同步的规则而不是新增分支是否存在硬编码的可变配置、无证据的默认值、重复的防御逻辑是否存在与任务无关的扩展speculative generality为想象中的未来预留接口。这条规则在 deveco-find-simplifications 中有更完整的展开没有生产消费者的 symbol/参数/配置/事件/缓存/测试产物、两处维护同一业务事实的实现、仅为测试或示例服务的抽象都是强简化候选但零引用本身不构成删除理由——外部脚本可能依赖 CLI 参数、输出与文件格式必须核实外部消费者。四、报告发现Report findings的规范审查报告的每条缺陷必须包含四要素位置、触发条件、影响、证据。优先级排序为错误行为 数据损坏 资源泄漏 兼容性回归 无效的质量检查。同时遵守建议与阻塞分离建议suggestion与阻塞blocker分开陈述不要混为一谈验证缺口显式标注未运行的路径要标记为 validation gap不能用应该没问题替代不重复已覆盖的发现已被通过的自动化检查覆盖的问题不再列出权限边界一次审查任务本身不授权代码编辑、发布审查评论或合并请求。五、配套 Skill 协作全景四个 Skill 如何支撑一次完整审查deveco-code-review 不是孤立的它与其余四个开发 Skill 形成闭环deveco-check-changes选择检查集负责在提交/推送/报告验证结果前从实际 diff 建立基线并路由证据TypeScript 实现/类型走npm run lintnpm test -- 相关路径不在自动覆盖内或涉及 CLI 注册/输出/入口/发布资源的代码要npm run build后经真实入口验证CI/依赖/package 脚本按受影响范围跑lint/test/build纯文案变更只需git diff --check 手工核对元数据与本地引用。它还强调超时、跳过、未运行的检查都不是通过fake hdc/hvigor/ohpm 测试不能建立与真实 Studio 安装、CLT 或设备的兼容性本地通过也不等于 GitCode pipeline 或分支保护已验证。deveco-test-reliability测试可靠性提供隔离、同步、取消、清理的完整决策框架见 3.7并明确在安静的机器上单机通过不足以证明可重复性。deveco-docs-and-prose文档与散文要求先识别文段中的每一个命题actor、动作、条件、时序、must/may/never 模态、异常、所有权、副作用、失败模式、后果再决定保留/增删/重构编辑前需对照当前代码、help 输出与实际运行验证事实验证命令名、相对 Markdown 链接与代码-文档一致性后运行git diff --check。deveco-find-simplifications简化候选在审查之外提供把表象复杂度转化为可评审的简化候选的方法论先用rg搜索精确符号/命令名/配置键/方法名/线串/动态加载入口再读调用者、公共接口、测试、README、脚本与配置将消费者分类为生产代码/测试文档/角色不确定的示例脚本。六、实战演练一次典型变更的审查路径以修改某个 CLI 子命令的 flag 与输出格式为例把上述规则串成一条可执行路径确认基线记录 base 与 target commit、worktree 状态读取完整 diff路由检查按 deveco-check-changes 的表格该变更落在CLI 注册、输出、入口行——先跑npm run lint再npm run build然后用构建产物packages/cli/dist/cli.js实际执行该子命令验证 flag、默认值、退出码与 stdout/stderr回归证据确认相关测试观察外部行为输出文本、退出码而非内部函数调用且对原始缺陷会失败用 vitest.config.ts 的 include 范围确认测试会被发现文档同步在同一 diff 内更新 SKILL.md 与 README.md 中对应命令/flag 的说明必要时更新 JSDoc生命周期检查若变更涉及子进程或锁如run --apply、--hotreload、MCP 重启按 3.3 追踪信号到最终进程并核对清理路径输出报告按位置、触发、影响、证据逐条列出建议与阻塞分开未运行路径标为验证缺口。七、审查底线与常见误区最后重申几条不容妥协的底线它们也是本 Skill 与 AGENTS.md 反复强调的口头描述不是证据结论必须能落到当前代码、测试或实际运行的命令上静默通过不是通过超时、跳过、未运行的检查都不能算验证通过检查失败必须停下修复或明确声明阻塞构建成功不等于入口可用npm run build只证明能编译用户入口必须通过构建产物真实执行验证fake 工具测试不等于真实兼容mock hdc/hvigor/ohpm 的测试不能证明与真实 Studio 安装、CLT 或设备的兼容性本地通过不等于远端验证本地测试通过不能证明 GitCode pipeline 或分支保护已验证推送/重写历史需要用户授权审查不等于修改授权一次代码审查任务不授权编辑代码、发布审查评论或合并请求。遵循以上流程开发者与 AI 编码助手即可在 deveco-cli 仓库中产出证据充分、范围聚焦、可被复核的代码审查结论为 CLI 与 MCP 这两条对外契约线守住质量底线。赞分享开发工具CLIOpenHarmonyMCP 服务移动开发【免费下载链接】deveco-cli集成HarmonyOS应用开发工具集提供知识文档和精品Skills支持多种智能体助力开发者使用AI辅助高效开发HarmonyOS应用。项目地址https://gitcode.com/openharmony-sig/deveco-cli点击查看免费下载相关推荐代码审查清单Android-PickerView代码审查清单Android PickerView 架构模块依赖符合设计无循环依赖 功能核心场景时间选择、联动选择测试通过 性能 WheelVie移动开发UI组件终极JavaScript代码审查清单团队协作的完整规范流程指南终极JavaScript代码审查清单团队协作的完整规范流程指南 在现代软件开发中保持代码质量和一致性是团队协作的核心挑战。GitHub加速计划下的idiomatomcode 的 Erlang 代码审查规则面向自动化评审员的六类检查清单与源码级原理atomcode 的 Erlang 代码审查规则面向自动化评审员的六类检查清单与源码级原理 atomcode 是 Rust 构建的开源 AI 编程助手其 a人工智能AI 应用AI Agent代码智能体CLIAI 评测上一篇开源项目Sushi概览与新手指南下一篇OpenUpgrade 项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考