2026/9/7 17:33:44
FEATURED · 精选文章 
ECC fsharp-reviewer 实战Kiro 中面向安全与函数式惯用法的 F# 代码评审 Agent【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本文以 ECC 仓库中 fsharp-reviewer Agent 的 Kiro 配置为主体完整拆解该评审 Agent 的触发流程、四级审查优先级CRITICAL/HIGH/MEDIUM、诊断命令与审批标准并结合仓库中同名的 Claude Code 版 Agent 定义 与 F# 专属规则集 rules/fsharp/ 说明这些审查项如何在真实项目中落地。读完本文你将掌握如何在 Kiro IDE 与 CLI 中安装并调用该 Agent它检查的每一类 F# 反模式对应的正确写法以及如何把dotnet buildfantomas诊断链接入自己的 F# 工程评审流程。一、fsharp-reviewer 是什么ECCEverything Claude Code为 Kiro 提供了一整套自定义 Agents、Skills、Hooks 与 Steering 文件其中fsharp-reviewer是专为 F# 项目设计的高级代码评审 Agent。其定位在文档 frontmatter 中写得很明确name: fsharp-reviewer description: Expert F# code reviewer specializing in functional idioms, type safety, pattern matching, computation expressions, and performance. Use for all F# code changes. MUST BE USED for F# projects. allowedTools: - read - shell两个要点能力边界由allowedTools约束该 Agent 只被授予read读取文件与shell执行诊断命令两类工具属于典型的只读 运行检查型评审角色不会直接改写被评审的代码。强制使用语义description 中 MUST BE USED for F# projects 表明它被设计为所有 F# 代码变更的默认评审者与 Kiro 中自动加载的 F# 规则文件 形成互补。仓库中同一 Agent 同时维护两种格式分别服务于不同入口格式路径使用方式Markdown.kiro/agents/fsharp-reviewer.mdKiro IDE 中通过/fsharp-reviewer调用JSON.kiro/agents/fsharp-reviewer.jsonkiro-cli中通过/agent swap或kiro-cli --agent fsharp-reviewer调用从 fsharp-reviewer.json 的结构看CLI 版本额外声明了tools: [builtin]、allowedTools: [fs_read, shell]与空的mcpServers/hooks其prompt字段与 Markdown 版本的正文逐字一致。按 Kiro 集成说明Agent 实际使用的模型由当前会话的模型选择决定而非 Agent 配置本身。安装方式为一次性拷贝不覆盖已有文件cd .kiro ./install.sh /path/to/your/project # 或 ./install.sh 安装到当前目录./install.sh ~ 全局安装二、被调用时的标准工作流Agent 提示词开头定义了固定的四步启动流程1. Run git diff -- *.fs *.fsx # 查看最近的 F# 文件变更 2. Run dotnet build and fantomas --check . if available 3. Focus on modified .fs and .fsx files 4. Begin review immediately这条流程的设计逻辑值得注意以 diff 为评审输入通过git diff的文件通配限定在*.fs/*.fsx评审范围天然聚焦在本次变更上而不是全库扫描先机器诊断、后语义评审dotnet build验证可编译性fantomas --check .验证格式规范fantomas是 F# 社区主流格式化工具--check模式只报告而不改写适合 CI 与评审场景立即开始评审要求 Agent 不做冗长铺垫直接进入检查清单。同名的 Claude Code 版 fsharp-reviewer 还额外带有一段 Prompt Defense Baseline提示注入防御基线要求评审时不泄露机密、不输出未经验证的可执行内容并将外部抓取的数据一律视为不可信——这在评审 Agent 读取第三方代码/文档时是一层实用防护。三、审查优先级体系CRITICAL → HIGH → MEDIUM该 Agent 的核心资产是一张按严重度分层的检查清单。以下完整继承原文档内容并补充每项的判定要点。CRITICAL - Security安全检查项反模式正确做法SQL 注入用字符串拼接/插值构造查询参数化查询命令注入Process.Start使用未验证输入校验并净化输入路径穿越用户可控的文件路径直接使用Path.GetFullPath 前缀检查不安全反序列化BinaryFormatter、不安全的 JSON 设置使用安全的序列化方案硬编码密钥API 密钥、连接串写死在源码中配置/密钥管理器CSRF/XSS缺少防伪令牌、视图输出未编码启用防伪机制、输出编码这些检查项在仓库的 F# 安全规则 中有更完整的落地示例。例如参数化查询用 Dapper 记录参数let findByCustomer (connection: IDbConnection) customerId task { let sql SELECT * FROM Orders WHERE CustomerId customerId return! connection.QueryAsyncOrder(sql, {| customerId customerId |}) }硬编码密钥的对照写法则是通过配置读取并以Option表达缺失// BAD let apiKey sk-live-123 // GOOD let apiKey configuration[OpenAI:ApiKey] | Option.ofObj | Option.defaultWith (fun () - failwith OpenAI:ApiKey is not configured.)CRITICAL - Error Handling错误处理吞掉异常with _ - ()或with _ - None—— 必须处理或重新抛出缺失资源释放手动Dispose—— 应使用use/use!绑定F# 对IDisposable的确定性资源管理惯用法阻塞 async.Result、.Wait()、.GetAwaiter().GetResult()—— 应改用let!/do!库代码中裸用failwith预期失败应改用Result或Option表达。仓库 F# 模式规则 中给出的是同一思想的正面写法用ResultT, TError 铁路导向编程替代异常处理预期失败type OrderError | InvalidCustomer of string | EmptyItems | ItemOutOfStock of sku: string let validateOrder (request: CreateOrderRequest) : ResultValidatedOrder, OrderError if String.IsNullOrWhiteSpace request.CustomerId then Error(InvalidCustomer CustomerId is required) elif request.Items | List.isEmpty then Error EmptyItems else Ok { CustomerId request.CustomerId; Items request.Items }HIGH - Functional Idioms函数式惯用法领域逻辑中的可变状态存在不可变替代时仍使用mutable、ref单元格不完备的模式匹配遗漏分支或使用掩盖新增 union 分支的兜底_这会破坏 discriminated union 的穷尽性保证命令式循环List.map、Seq.filter、Array.fold更能表达意图时仍写for/while使用 null缺失值应使用OptionT过度面向对象module 函数 记录即可胜任时仍建 OOP 类。编码风格规则 对前两项给了明确的对照示例——记录默认不可变、用with表达式做更新let rename (profile: UserProfile) newName { profile with Name newName }以及用类型建模替代类层次type EmailAddress EmailAddress of string type OrderStatus | Pending | Confirmed of confirmedAt: DateTimeOffset | Shipped of trackingNumber: string | Cancelled of reason: stringHIGH - Type Safety类型安全基本类型偏执Primitive Obsession用裸string/int表达领域概念 —— 应使用单 case 判别式联合如上面的EmailAddress of string边界未验证输入系统边界缺少验证 —— 应使用智能构造器smart constructors不安全向下转型无类型测试的:?—— 应使用模式匹配:? T as tobj使用避免值类型经由obj装箱优先泛型或显式联合类型。智能构造器在 安全规则 中有完整示例私有构造 静态create函数返回Result使非法值在类型层面无法被构造出来type ValidatedEmail private ValidatedEmail of string module ValidatedEmail let create (input: string) if System.Text.RegularExpressions.Regex.IsMatch(input, ^[^][^]\.[^]$) then Ok(ValidatedEmail input) else Error Invalid email address let value (ValidatedEmail v) vHIGH - Code Quality代码质量大函数超过 40 行 —— 抽取辅助函数深层嵌套超过 3 层 —— 使用早返回、Result.bind或计算表达式缺少[RequireQualifiedAccess]可能导致命名冲突的 module/union 应加上该属性无用的open声明删除未使用的模块导入。关于[RequireQualifiedAccess]模式规则 展示了它对模块组织的实际价值[RequireQualifiedAccess] module Order let create customerId items { Id Guid.NewGuid(); CustomerId customerId; Items items; Status Pending } let confirm order { order with Status Confirmed(DateTimeOffset.UtcNow) }同时该规则文件约定了open声明的分组顺序System.*→Microsoft.*→ 第三方 → 项目自身命名空间组内按字典序排列可作为清理无用open后的重排依据。MEDIUM - Performance性能热路径上的Seq惰性序列被反复重算 —— 用Seq.toList/Seq.toArray物化循环中字符串拼接使用StringBuilder或String.concat过度装箱值类型经obj传递 —— 使用泛型函数N1 查询EF Core 循环中懒加载 —— 改用急切加载。MEDIUM - Best Practices最佳实践命名规范函数/值用 camelCase类型/模块/DU 分支用 PascalCase管道运算符可读性过长的|链拆成具名中间绑定计算表达式误用task { task { } }嵌套 —— 用let!展平模块组织相关函数散落各文件 —— 按内聚性归组。编码风格规则 展示了管道 Result 链的标准形态正是上面两条最佳实践的直接体现let processOrder order order | validateItems | Result.bind calculateTotal | Result.map applyDiscount | Result.mapError OrderError四、诊断命令与审批标准Agent 内置了一组可直接执行的诊断命令dotnet build # 编译检查 fantomas --check . # 格式检查 dotnet test --no-build # 运行测试 dotnet test --collect:XPlat Code Coverage # 收集覆盖率这四条命令覆盖了可编译 → 格式合规 → 测试通过 → 覆盖率可见的完整质量链。对应的仓库 F# Hooks 规则 建议把前三条接到编辑后的自动钩子上PostToolUse阶段跑fantomas自动格式化与dotnet build编译验证行为变更后重跑dotnet test --no-buildStop阶段会话结束前做最后一次dotnet build并对被修改的appsettings*.json发出告警以防密钥入库。审批标准只有三档判定边界清晰Approve无 CRITICAL 或 HIGH 问题Warning仅 MEDIUM 问题可谨慎合并Block发现 CRITICAL 或 HIGH 问题。Claude Code 版 Agent 额外规定了一个统一的输出格式保证评审结论可被逐条定位[SEVERITY] Issue title File: path/to/File.fs:42 Issue: Description Fix: What to change即每条发现都带严重度、精确到文件与行号的问题描述、以及明确的修复方向。五、框架专项检查通用清单之外Agent 针对三个 F# 常见技术栈定义了专项检查点ASP.NET CoreGiraffe 或 Saturn 处理程序、模型验证、认证策略、中间件顺序EF Core迁移安全性、急切加载、只读查询使用AsNoTrackingFableElmish 架构、消息处理完备性、view 函数纯度。这三组检查点体现了 F# 生态的两个特点Web 层常用 Giraffe/Saturn 这类轻量框架而非标准 MVC 模板前端则有 FableF# 编译到 JS这一独特赛道其 Elmish 架构要求消息处理的穷尽性与 view 纯函数性恰好与前面不完备模式匹配的 HIGH 级检查项呼应。六、配套规则集让评审标准在编辑时就生效单靠评审 Agent 是事后把关。ECC 仓库还为 F# 提供了一组按文件路径自动加载的规则frontmatter 中paths: [**/*.fs, **/*.fsx]使同样的标准在编码阶段即生效规则文件内容coding-style.md不可变性默认、DU 建模、管道风格、open声明分组、fantomas 格式化patterns.mdResult铁路编程、Option处理缺失值、计算表达式、record-of-functions 式依赖注入security.md密钥管理、参数化查询、智能构造器输入验证、认证授权与错误信息脱敏testing.mdxUnit FsUnit.xUnit、Unquote 断言、FsCheck 属性测试、WebApplicationFactory集成测试、80% 行覆盖目标hooks.md编辑后自动 fantomas/编译/测试钩子配置例如测试规则中给出的 FsCheck 属性测试正好对应评审清单中预期失败用 Result 表达的验证方式open FsCheck.Xunit [Property] let order total is never negative (items: OrderItem list) let total Order.calculateTotal items total 0m七、实际使用方式在 Kiro 中启用该 Agent 有两条路径均源自 Kiro 集成说明IDE 会话在输入框输入/fsharp-reviewer然后描述评审范围例如评审 src/ 下本次改动的 Order 相关模块CLIkiro-cli --agent fsharp-reviewer # 直接以该 Agent 启动会话 # 或在会话内/agent swap fsharp-reviewer一个贴合该 Agent 定位的典型工作流是F# 功能开发完成后切换到fsharp-reviewer它自动执行git diff -- *.fs *.fsx圈定范围跑dotnet build与fantomas --check .拿到机器证据再按 CRITICAL → HIGH → MEDIUM 清单输出带文件行号的结构化发现最后给出 Approve/Warning/Block 结论若结论为 Block修复后重新触发评审直至达到 Approve。八、小结评审视角的底层原则Agent 提示词结尾给出了一句话心法可以作为理解整套检查清单的钥匙Is this idiomatic F# that leverages the type system and functional patterns effectively?这是不是充分利用了类型系统与函数式模式的惯用 F#从这个视角回看各级检查项CRITICAL 层守住安全与错误处理的底线HIGH 层的函数式惯用法与类型安全实际上都在要求把领域不变量推进类型系统——用 DU 穷尽性替代 if/else 分支、用单 case 联合与智能构造器消灭非法状态、用Option/Result取代 null 与异常MEDIUM 层则处理性能与可读性的工程细节。配合dotnet buildfantomasdotnet test的机器诊断链和三级审批标准这份 Agent 配置本质上是一份可执行的 F# 代码评审规范其检查项与仓库 F# 规则集 一一对应可直接作为 F# 工程在 AI 辅助开发场景下的评审基线参考。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ECC fsharp-reviewer 实战：Kiro 中面向安全与函数式惯用法的 F 代码评审 Agent
ECC fsharp-reviewer 实战Kiro 中面向安全与函数式惯用法的 F# 代码评审 Agent【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本文以 ECC 仓库中 fsharp-reviewer Agent 的 Kiro 配置为主体完整拆解该评审 Agent 的触发流程、四级审查优先级CRITICAL/HIGH/MEDIUM、诊断命令与审批标准并结合仓库中同名的 Claude Code 版 Agent 定义 与 F# 专属规则集 rules/fsharp/ 说明这些审查项如何在真实项目中落地。读完本文你将掌握如何在 Kiro IDE 与 CLI 中安装并调用该 Agent它检查的每一类 F# 反模式对应的正确写法以及如何把dotnet buildfantomas诊断链接入自己的 F# 工程评审流程。一、fsharp-reviewer 是什么ECCEverything Claude Code为 Kiro 提供了一整套自定义 Agents、Skills、Hooks 与 Steering 文件其中fsharp-reviewer是专为 F# 项目设计的高级代码评审 Agent。其定位在文档 frontmatter 中写得很明确name: fsharp-reviewer description: Expert F# code reviewer specializing in functional idioms, type safety, pattern matching, computation expressions, and performance. Use for all F# code changes. MUST BE USED for F# projects. allowedTools: - read - shell两个要点能力边界由allowedTools约束该 Agent 只被授予read读取文件与shell执行诊断命令两类工具属于典型的只读 运行检查型评审角色不会直接改写被评审的代码。强制使用语义description 中 MUST BE USED for F# projects 表明它被设计为所有 F# 代码变更的默认评审者与 Kiro 中自动加载的 F# 规则文件 形成互补。仓库中同一 Agent 同时维护两种格式分别服务于不同入口格式路径使用方式Markdown.kiro/agents/fsharp-reviewer.mdKiro IDE 中通过/fsharp-reviewer调用JSON.kiro/agents/fsharp-reviewer.jsonkiro-cli中通过/agent swap或kiro-cli --agent fsharp-reviewer调用从 fsharp-reviewer.json 的结构看CLI 版本额外声明了tools: [builtin]、allowedTools: [fs_read, shell]与空的mcpServers/hooks其prompt字段与 Markdown 版本的正文逐字一致。按 Kiro 集成说明Agent 实际使用的模型由当前会话的模型选择决定而非 Agent 配置本身。安装方式为一次性拷贝不覆盖已有文件cd .kiro ./install.sh /path/to/your/project # 或 ./install.sh 安装到当前目录./install.sh ~ 全局安装二、被调用时的标准工作流Agent 提示词开头定义了固定的四步启动流程1. Run git diff -- *.fs *.fsx # 查看最近的 F# 文件变更 2. Run dotnet build and fantomas --check . if available 3. Focus on modified .fs and .fsx files 4. Begin review immediately这条流程的设计逻辑值得注意以 diff 为评审输入通过git diff的文件通配限定在*.fs/*.fsx评审范围天然聚焦在本次变更上而不是全库扫描先机器诊断、后语义评审dotnet build验证可编译性fantomas --check .验证格式规范fantomas是 F# 社区主流格式化工具--check模式只报告而不改写适合 CI 与评审场景立即开始评审要求 Agent 不做冗长铺垫直接进入检查清单。同名的 Claude Code 版 fsharp-reviewer 还额外带有一段 Prompt Defense Baseline提示注入防御基线要求评审时不泄露机密、不输出未经验证的可执行内容并将外部抓取的数据一律视为不可信——这在评审 Agent 读取第三方代码/文档时是一层实用防护。三、审查优先级体系CRITICAL → HIGH → MEDIUM该 Agent 的核心资产是一张按严重度分层的检查清单。以下完整继承原文档内容并补充每项的判定要点。CRITICAL - Security安全检查项反模式正确做法SQL 注入用字符串拼接/插值构造查询参数化查询命令注入Process.Start使用未验证输入校验并净化输入路径穿越用户可控的文件路径直接使用Path.GetFullPath 前缀检查不安全反序列化BinaryFormatter、不安全的 JSON 设置使用安全的序列化方案硬编码密钥API 密钥、连接串写死在源码中配置/密钥管理器CSRF/XSS缺少防伪令牌、视图输出未编码启用防伪机制、输出编码这些检查项在仓库的 F# 安全规则 中有更完整的落地示例。例如参数化查询用 Dapper 记录参数let findByCustomer (connection: IDbConnection) customerId task { let sql SELECT * FROM Orders WHERE CustomerId customerId return! connection.QueryAsyncOrder(sql, {| customerId customerId |}) }硬编码密钥的对照写法则是通过配置读取并以Option表达缺失// BAD let apiKey sk-live-123 // GOOD let apiKey configuration[OpenAI:ApiKey] | Option.ofObj | Option.defaultWith (fun () - failwith OpenAI:ApiKey is not configured.)CRITICAL - Error Handling错误处理吞掉异常with _ - ()或with _ - None—— 必须处理或重新抛出缺失资源释放手动Dispose—— 应使用use/use!绑定F# 对IDisposable的确定性资源管理惯用法阻塞 async.Result、.Wait()、.GetAwaiter().GetResult()—— 应改用let!/do!库代码中裸用failwith预期失败应改用Result或Option表达。仓库 F# 模式规则 中给出的是同一思想的正面写法用ResultT, TError 铁路导向编程替代异常处理预期失败type OrderError | InvalidCustomer of string | EmptyItems | ItemOutOfStock of sku: string let validateOrder (request: CreateOrderRequest) : ResultValidatedOrder, OrderError if String.IsNullOrWhiteSpace request.CustomerId then Error(InvalidCustomer CustomerId is required) elif request.Items | List.isEmpty then Error EmptyItems else Ok { CustomerId request.CustomerId; Items request.Items }HIGH - Functional Idioms函数式惯用法领域逻辑中的可变状态存在不可变替代时仍使用mutable、ref单元格不完备的模式匹配遗漏分支或使用掩盖新增 union 分支的兜底_这会破坏 discriminated union 的穷尽性保证命令式循环List.map、Seq.filter、Array.fold更能表达意图时仍写for/while使用 null缺失值应使用OptionT过度面向对象module 函数 记录即可胜任时仍建 OOP 类。编码风格规则 对前两项给了明确的对照示例——记录默认不可变、用with表达式做更新let rename (profile: UserProfile) newName { profile with Name newName }以及用类型建模替代类层次type EmailAddress EmailAddress of string type OrderStatus | Pending | Confirmed of confirmedAt: DateTimeOffset | Shipped of trackingNumber: string | Cancelled of reason: stringHIGH - Type Safety类型安全基本类型偏执Primitive Obsession用裸string/int表达领域概念 —— 应使用单 case 判别式联合如上面的EmailAddress of string边界未验证输入系统边界缺少验证 —— 应使用智能构造器smart constructors不安全向下转型无类型测试的:?—— 应使用模式匹配:? T as tobj使用避免值类型经由obj装箱优先泛型或显式联合类型。智能构造器在 安全规则 中有完整示例私有构造 静态create函数返回Result使非法值在类型层面无法被构造出来type ValidatedEmail private ValidatedEmail of string module ValidatedEmail let create (input: string) if System.Text.RegularExpressions.Regex.IsMatch(input, ^[^][^]\.[^]$) then Ok(ValidatedEmail input) else Error Invalid email address let value (ValidatedEmail v) vHIGH - Code Quality代码质量大函数超过 40 行 —— 抽取辅助函数深层嵌套超过 3 层 —— 使用早返回、Result.bind或计算表达式缺少[RequireQualifiedAccess]可能导致命名冲突的 module/union 应加上该属性无用的open声明删除未使用的模块导入。关于[RequireQualifiedAccess]模式规则 展示了它对模块组织的实际价值[RequireQualifiedAccess] module Order let create customerId items { Id Guid.NewGuid(); CustomerId customerId; Items items; Status Pending } let confirm order { order with Status Confirmed(DateTimeOffset.UtcNow) }同时该规则文件约定了open声明的分组顺序System.*→Microsoft.*→ 第三方 → 项目自身命名空间组内按字典序排列可作为清理无用open后的重排依据。MEDIUM - Performance性能热路径上的Seq惰性序列被反复重算 —— 用Seq.toList/Seq.toArray物化循环中字符串拼接使用StringBuilder或String.concat过度装箱值类型经obj传递 —— 使用泛型函数N1 查询EF Core 循环中懒加载 —— 改用急切加载。MEDIUM - Best Practices最佳实践命名规范函数/值用 camelCase类型/模块/DU 分支用 PascalCase管道运算符可读性过长的|链拆成具名中间绑定计算表达式误用task { task { } }嵌套 —— 用let!展平模块组织相关函数散落各文件 —— 按内聚性归组。编码风格规则 展示了管道 Result 链的标准形态正是上面两条最佳实践的直接体现let processOrder order order | validateItems | Result.bind calculateTotal | Result.map applyDiscount | Result.mapError OrderError四、诊断命令与审批标准Agent 内置了一组可直接执行的诊断命令dotnet build # 编译检查 fantomas --check . # 格式检查 dotnet test --no-build # 运行测试 dotnet test --collect:XPlat Code Coverage # 收集覆盖率这四条命令覆盖了可编译 → 格式合规 → 测试通过 → 覆盖率可见的完整质量链。对应的仓库 F# Hooks 规则 建议把前三条接到编辑后的自动钩子上PostToolUse阶段跑fantomas自动格式化与dotnet build编译验证行为变更后重跑dotnet test --no-buildStop阶段会话结束前做最后一次dotnet build并对被修改的appsettings*.json发出告警以防密钥入库。审批标准只有三档判定边界清晰Approve无 CRITICAL 或 HIGH 问题Warning仅 MEDIUM 问题可谨慎合并Block发现 CRITICAL 或 HIGH 问题。Claude Code 版 Agent 额外规定了一个统一的输出格式保证评审结论可被逐条定位[SEVERITY] Issue title File: path/to/File.fs:42 Issue: Description Fix: What to change即每条发现都带严重度、精确到文件与行号的问题描述、以及明确的修复方向。五、框架专项检查通用清单之外Agent 针对三个 F# 常见技术栈定义了专项检查点ASP.NET CoreGiraffe 或 Saturn 处理程序、模型验证、认证策略、中间件顺序EF Core迁移安全性、急切加载、只读查询使用AsNoTrackingFableElmish 架构、消息处理完备性、view 函数纯度。这三组检查点体现了 F# 生态的两个特点Web 层常用 Giraffe/Saturn 这类轻量框架而非标准 MVC 模板前端则有 FableF# 编译到 JS这一独特赛道其 Elmish 架构要求消息处理的穷尽性与 view 纯函数性恰好与前面不完备模式匹配的 HIGH 级检查项呼应。六、配套规则集让评审标准在编辑时就生效单靠评审 Agent 是事后把关。ECC 仓库还为 F# 提供了一组按文件路径自动加载的规则frontmatter 中paths: [**/*.fs, **/*.fsx]使同样的标准在编码阶段即生效规则文件内容coding-style.md不可变性默认、DU 建模、管道风格、open声明分组、fantomas 格式化patterns.mdResult铁路编程、Option处理缺失值、计算表达式、record-of-functions 式依赖注入security.md密钥管理、参数化查询、智能构造器输入验证、认证授权与错误信息脱敏testing.mdxUnit FsUnit.xUnit、Unquote 断言、FsCheck 属性测试、WebApplicationFactory集成测试、80% 行覆盖目标hooks.md编辑后自动 fantomas/编译/测试钩子配置例如测试规则中给出的 FsCheck 属性测试正好对应评审清单中预期失败用 Result 表达的验证方式open FsCheck.Xunit [Property] let order total is never negative (items: OrderItem list) let total Order.calculateTotal items total 0m七、实际使用方式在 Kiro 中启用该 Agent 有两条路径均源自 Kiro 集成说明IDE 会话在输入框输入/fsharp-reviewer然后描述评审范围例如评审 src/ 下本次改动的 Order 相关模块CLIkiro-cli --agent fsharp-reviewer # 直接以该 Agent 启动会话 # 或在会话内/agent swap fsharp-reviewer一个贴合该 Agent 定位的典型工作流是F# 功能开发完成后切换到fsharp-reviewer它自动执行git diff -- *.fs *.fsx圈定范围跑dotnet build与fantomas --check .拿到机器证据再按 CRITICAL → HIGH → MEDIUM 清单输出带文件行号的结构化发现最后给出 Approve/Warning/Block 结论若结论为 Block修复后重新触发评审直至达到 Approve。八、小结评审视角的底层原则Agent 提示词结尾给出了一句话心法可以作为理解整套检查清单的钥匙Is this idiomatic F# that leverages the type system and functional patterns effectively?这是不是充分利用了类型系统与函数式模式的惯用 F#从这个视角回看各级检查项CRITICAL 层守住安全与错误处理的底线HIGH 层的函数式惯用法与类型安全实际上都在要求把领域不变量推进类型系统——用 DU 穷尽性替代 if/else 分支、用单 case 联合与智能构造器消灭非法状态、用Option/Result取代 null 与异常MEDIUM 层则处理性能与可读性的工程细节。配合dotnet buildfantomasdotnet test的机器诊断链和三级审批标准这份 Agent 配置本质上是一份可执行的 F# 代码评审规范其检查项与仓库 F# 规则集 一一对应可直接作为 F# 工程在 AI 辅助开发场景下的评审基线参考。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 )
