mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-14 02:42:04 +08:00
4061ae48c4
- Added integration tests for adaptive RRF weights in hybrid search. - Enhanced query intent detection with new classifications: keyword, semantic, and mixed. - Introduced symbol boosting in search results based on explicit symbol matches. - Implemented embedding-based reranking with configurable options. - Added global symbol index for efficient symbol lookups across projects. - Improved file deletion handling on Windows to avoid permission errors. - Updated chunk configuration to increase overlap for better context. - Modified package.json test script to target specific test files. - Created comprehensive writing style guidelines for documentation. - Added TypeScript tests for query intent detection and adaptive weights. - Established performance benchmarks for global symbol indexing.
5.2 KiB
5.2 KiB
写作风格规范
核心原则
段落式描述，层层递进，禁止清单罗列。
禁止的写作模式
<!-- 禁止：清单罗列 -->
### 模块列表
- 用户模块：处理用户相关功能
- 订单模块：处理订单相关功能
- 支付模块：处理支付相关功能
### 依赖关系
| 模块 | 依赖 | 说明 |
|------|------|------|
| A | B | xxx |
推荐的写作模式
<!-- 推荐：段落式描述 -->
### 模块架构设计
系统采用分层模块化架构，核心业务逻辑围绕用户、订单、支付三大领域展开。
用户模块作为系统的入口层，承担身份认证与权限管理职责，为下游模块提供
统一的用户上下文。订单模块位于业务核心层，依赖用户模块获取会话信息，
并协调支付模块完成交易闭环。
值得注意的是，支付模块采用策略模式实现多渠道支付，通过接口抽象与
具体支付网关解耦。这一设计使得新增支付渠道时，仅需实现相应策略类，
无需修改核心订单逻辑，体现了开闭原则的应用。
从依赖方向分析，系统呈现清晰的单向依赖：表现层依赖业务层，业务层
依赖数据层，未发现循环依赖。这一架构特征确保了模块的独立可测试性，
同时为后续微服务拆分奠定了基础。
写作策略
策略一：主语转换
将主语从开发者视角转移到系统/代码本身：
| 禁止 | 推荐 |
|---|---|
| 我们设计了... | 系统采用... |
| 开发者实现了... | 该模块通过... |
| 代码中使用了... | 架构设计体现了... |
策略二：逻辑连接
使用连接词确保段落递进：
- 承接：此外、进一步、在此基础上
- 转折：然而、值得注意的是、不同于
- 因果：因此、这一设计使得、由此可见
- 总结：综上所述、从整体来看、概言之
策略三：深度阐释
每个技术点需包含：
- 是什么：客观描述技术实现
- 为什么：阐释设计意图和考量
- 影响：说明对系统的影响和价值
<!-- 示例 -->
系统采用依赖注入模式管理组件生命周期（是什么）。这一选择源于
对可测试性和松耦合的追求（为什么）。通过将依赖关系外置于
配置层，各模块可独立进行单元测试，同时为运行时替换实现
提供了可能（影响）。
章节模板
架构概述（段落式）
## 系统架构概述
{项目名称}采用{架构模式}架构，整体设计围绕{核心理念}展开。
从宏观视角审视，系统可划分为{N}个主要层次，各层职责明确，
边界清晰。
{表现层/入口层}作为系统与外部交互的唯一入口，承担请求解析、
参数校验、响应封装等职责。该层通过{框架/技术}实现，遵循
{设计原则}，确保接口的一致性与可维护性。
{业务层}是系统的核心所在，封装了全部业务逻辑。该层采用
{模式/策略}组织代码，将复杂业务拆解为{N}个领域模块。
值得注意的是，{关键设计决策}体现了对{质量属性}的重视。
{数据层}负责持久化与数据访问，通过{技术/框架}实现。
该层与业务层通过{接口/抽象}解耦，使得数据源的替换
不影响上层逻辑，体现了依赖倒置原则的应用。
设计模式分析（段落式）
## 设计模式应用
代码库中可识别出{模式1}、{模式2}等设计模式的应用，
这些模式的选择与系统的{核心需求}密切相关。
{模式1}主要应用于{场景/模块}。具体实现位于
`{文件路径}`，通过{实现方式}达成{目标}。
这一模式的引入有效解决了{问题}，使得{效果}。
在{另一场景}中，系统采用{模式2}应对{挑战}。
不同于{模式1}的{特点}，{模式2}更侧重于{关注点}。
从`{文件路径}`的实现可以看出，设计者通过
{具体实现}实现了{目标}。
综合来看，模式的选择体现了对{原则}的遵循，
为系统的{质量属性}提供了有力支撑。
算法流程分析（段落式）
## 核心算法设计
{算法名称}是系统处理{业务场景}的核心逻辑，
其实现位于`{文件路径}`。
从算法流程来看，整体可分为{N}个阶段。首先，
{第一阶段描述}，这一步骤的目的在于{目的}。
随后，算法进入{第二阶段}，通过{方法}实现{目标}。
最终，{结果处理}完成整个处理流程。
在复杂度方面，该算法的时间复杂度为{O(x)}，
空间复杂度为{O(y)}。这一复杂度特征源于
{原因}，在{数据规模}场景下表现良好。
值得关注的是，{算法名称}采用了{优化策略}，
相较于朴素实现，{具体优化点}。这一设计决策
使得{性能提升/效果}。
质量检查清单
- 无清单罗列（禁止
-或|表格作为主体内容） - 段落完整（每段 3-5 句，逻辑闭环）
- 逻辑递进（有连接词串联）
- 客观表达（无"我们"、"开发者"等主观主语）
- 深度阐释（包含是什么/为什么/影响）
- 代码引用（关键点附文件路径）