Linter

想象一下，你请一个人工来为你制作一个书架。最终交给你的作品看上去很漂亮：架子、螺丝，一切都井井有条。但是你把书架靠在墙上，结果它倒下了。那些螺丝只是道具，看着像螺丝，但其实是塑料做的。 这就是LLM（大语言模型）滥用类型系统时的表现。它交给你的代码可以编译、能通过测试、格式上看起来挑不出毛病。但内部本该是有意义的类型，却被填上了字符串（string）。本该有明确状态的地方，用了nil，而它的意义因读代码的人而异。本该是一个有两个案例的枚举，却被换成了一个== "claude"，某天有人可能会写成错拼的== "cladue"，但你要等到线上了才会发现。 模型的最爱捷径：万能的字符串 过去几个月，我一直和一个AI助手合作，开发一个中型的Swift应用。它生成的代码干净、结构清晰、命名合理。但有一个模式一再出现：模型尽量避免创建新类型。 这不是因为它懒惰，而是因为创建新类型需要做设计决策，比如：这是一个枚举（enum）吗？有多少个可能值？应该放在哪儿？由谁来导入？而String则无需任何决策。它可以放在任何地方，总是可以编译。 结果就是会生成这样的代码： func sessions(harness: String? = nil) -> [Session] { if let harness { return all.filter { $0.harness == harness } } return all } // 用法： let claudeSessions = sessions(harness: "claude") let codexSessions = sessions(harness: "codex") --- 看起来没问题，确实能运行。但这个代码有三个隐藏的问题： 1. **如果你写错了`"cladue"`，没人会提醒你。**字符串可以是任何内容，但如果是枚举类型，这种错误是可以避免的。 2. **`nil`被用来表示“全部”。** 但这不是定义在某个类型中，而是一种存在于代码注释中、甚至仅仅是你的大脑中的约定。 3. **每个按`harness`过滤的函数都重复了同样的`String? = nil`模式。** 如果你以后想添加一个第三种`harness`，就必须手动搜遍代码中所有的字符串比较。 换句话说，编译器无法帮助你，因为你剥夺了它所有的语义信息。你用一个`String`代替了领域概念。 ## 模型应该写成这样 ```swift enum HarnessID: String, Codable { case claude case codex } enum HarnessFilter { case all case specific(HarnessID) } func sessions(harness: HarnessFilter = .all) -> [Session] { switch harness { case .all: return all case .specific(let id): return all.filter { $0.harnessID == id } } } // 用法： let claudeSessions = sessions(harness: .specific(.claude)) let allSessions = sessions() // 默认是.all — 很明确 现在，"cladue"不会编译。“全部”不再是一个含糊不清的nil，而是一个显式的枚举情况。如果你添加一个第三个harness，编译器会强制你在每个switch语句中处理新情况。它将运行时错误转化为了编译时错误。这才是类型系统本该发挥的作用。 ...