真正承载论点的是代码结构而非注释，应优先解析MethodDeclarationSyntax、IfStatementSyntax和ThrowStatementSyntax等AST节点，提取带变量名和逻辑关系的可验证断言，并附源码位置供核验。
用正则硬匹配注释里的“// 论点：”行会漏掉大部分真实场景
纯靠写死关键词去扫 // 论点： 或 /// ，实际项目里基本没用——人写的注释格式五花八门，有中文冒号、英文冒号、空格不一致、换行缩进混乱，甚至混在 XML 文档注释中间。更关键的是，真正承载论点的往往不是注释，而是方法名、参数命名、if 条件判断、return 值或异常抛出逻辑。
- 优先扫描函数签名和返回类型：
bool IsEligibleForDiscount()比注释更可靠地暗示“是否满足折扣条件”这一论点 - 检查
throw new ArgumentException("金额不能为负")这类语句，它隐含“金额必须非负”的约束性论点 - 跳过所有
///块——它们常是模板填充内容，和实际逻辑脱节 - 别碰
#region里的文字标题，90% 是“业务逻辑”“辅助方法”这种无效标签
C# AST 解析比字符串搜索靠谱，但 Roslyn API 入口容易选错
直接读取 .cs 文件文本做替换或切分，永远绕不开编码、BOM、跨行字符串、注释嵌套这些坑。Roslyn 的 CSharpSyntaxTree.ParseText() 能准确识别语法结构，但新手常卡在选错节点类型上。
- 要提取“论点”，重点盯
MethodDeclarationSyntax和IfStatementSyntax，而不是CommentTrivia -
ParameterSyntax的Type和Identifier组合能暴露隐含前提，比如decimal amount+int discountRate暗示“金额与折扣率参与计算” - 别用
SyntaxTree.GetRoot().DescendantNodes()全遍历——性能差且噪声大；改用root.DescendantNodes().OfType精准抓条件分支() - Roslyn 默认不加载引用程序集，遇到
IEnumerable或自定义泛型类型时会报UnknownType，得手动传入MetadataReference
论点不是名词短语，而是带判断倾向的语义单元
把 IsValid 直接当论点输出成“有效性”，等于没干——它缺主语、缺上下文、缺真假判定依据。真实可用的论点必须包含可验证的逻辑断言，比如“订单总金额大于等于满减门槛时才触发优惠计算”。
- 从
if (order.Total >= threshold)提炼论点时，保留变量名和比较关系，生成字符串："order.Total >= threshold"，而不是抽象成“金额达标” - 对
return result ?? throw new InvalidOperationException()，论点应是“result 不为空是正常返回的前提”，而非“避免空引用” - 多个
if并列时，不要合并成一句“需满足所有条件”——每个分支独立对应一个论点，顺序和嵌套层级本身就是逻辑权重信号 - 警惕布尔属性名误导，
IsLegacyMode是事实陈述，ShouldRetryOnFailure才含动作建议类论点
别试图一步到位做 NLP，先用规则锚定高置信片段
在 C# 代码里跑 spaCy 或调用 LLM 接口，既慢又不准——模型没见过 nameof()、?.、async/await 的语义惯用法，还容易把测试用例里的假数据当真逻辑。
- 第一版只处理三类高价值节点：
MethodDeclarationSyntax（方法意图）、IfStatementSyntax（判断前提）、ThrowStatementSyntax（约束边界） - 每条提取结果附带源码位置：
file.cs(42,15)，方便人工核验，也避免把重构残留的旧注释当真 - 加个简单过滤：去掉含
Test、Mock、Sample的方法名，它们的逻辑不代表生产约束 - 输出别用 JSON 数组包一堆字符串，就用制表符分隔的纯文本：
IsOrderValid\torder.Status == OrderStatus.Confirmed\tOrderService.cs(87,22)
真正难的不是识别单个论点，而是理解多个论点之间的依赖和冲突——比如一个方法同时检查 user.IsPremium 和 user.TrialDaysLeft > 0，这两个论点在业务上可能是互斥前提，但代码里看不出。这种层面上的推理，目前没法靠静态分析自动补全。
