预计阅读时间：11 分钟
一位做了十年金融支付系统的工程师突然发现：自己花数年积累的 PCI 合规知识、双复式记账逻辑、银行转账幂等性设计，现在 Claude 和 GPT-4 也能在几分钟内给出相当不错的实现。这种冲击不是幻觉——它正在真实地改变"领域专家"的议价能力。
领域知识的壁垒正在被稀释
过去，一个支付系统的核心价值在于工程师对业务规则的深度理解。比如"双复式记账"听起来简单，但真正在支付系统里落地，要处理的部分远超教科书：
- 同一笔交易在两个账户体系间必须原子性记账
- 退款要冲正原交易、不能直接负数记账
- 跨日结算时挂账与冲账的时间窗口
- 银行回调延迟导致的对账差异处理
十年前，能把这些写对的人凤毛麟角。现在，把上述约束喂给 LLM，它能生成一个结构合理的记账模型，甚至附带测试用例。领域知识的"稀缺性"被大幅稀释了。
但"稀释"不等于"归零"——LLM 生成的是符合常见模式的代码，它不知道你公司那套和历史数据兼容的奇怪对账规则，也不知道你们银行接口那个 undocumented 的超时行为。细节中的魔鬼，仍然是人的战场。
LLM 擅长的和它搞不定的
LLM 在支付领域真正擅长的：
- 生成标准模式的代码骨架（CRUD、状态机、幂等框架）
- 解释合规文档的要点（PCI DSS 的条文它读得比大多数人快）
- 快速产出单元测试和集成测试的覆盖框架
它搞不定的：
- 你们系统里那个因为 2017 年一次数据迁移导致的对账偏移量
- 第三方银行接口在周五下午 4 点后静默拒绝但返回 200 的行为
- 需要和法务团队反复确认的跨境资金托管合规边界
换句话说，LLM 能覆盖"教科书知识"，但教科书知识从来不是高级工程师的核心价值。核心价值在于把教科书知识适配到一团乱麻的现实系统里。
实践：用 LLM 加速但不被它替代
与其焦虑，不如把 LLM 当成"领域知识的快速原型工具"，然后把自己的价值锚定在它做不到的地方。下面是一个具体的实践模式——用 LLM 生成记账核心逻辑，再由人工补上业务特例。
第一步：让 LLM 生成双复式记账的骨架
# prompt: 实现一个支持双复式记账的 TransactionService，
# 要求每笔交易同时记录借方和贷方，金额必须平衡，
# 支持幂等性（同一 transaction_id 不重复记账）
from dataclasses import dataclass
from enum import Enum
from typing import Optional
class EntrySide(Enum):
DEBIT = "debit"
CREDIT = "credit"
@dataclass
class LedgerEntry:
account_id: str
side: EntrySide
amount: int # 用整数表示分，避免浮点精度问题
transaction_id: str
description: str
class TransactionService:
"""LLM 生成的标准双复式记账骨架——逻辑正确但缺少业务特例"""
def __init__(self, ledger_store):
self.ledger_store = ledger_store
def record_transaction(
self,
transaction_id: str,
debit_account: str,
credit_account: str,
amount: int,
description: str = "",
) -> bool:
# 幂等性检查：已存在的 transaction_id 直接返回成功
if self.ledger_store.exists(transaction_id):
return True
entries = [
LedgerEntry(debit_account, EntrySide.DEBIT, amount,
transaction_id, description),
LedgerEntry(credit_account, EntrySide.CREDIT, amount,
transaction_id, description),
]
# 借贷必须平衡
debit_total = sum(e.amount for e in entries if e.side == EntrySide.DEBIT)
credit_total = sum(e.amount for e in entries if e.side == EntrySide.CREDIT)
if debit_total != credit_total:
raise ValueError(f"Unbalanced: debit={debit_total}, credit={credit_total}")
self.ledger_store.atomic_write(entries)
return True
这段代码结构清晰、逻辑正确，一个初级工程师可能要半天才能写出来，LLM 两分钟就交付了。但——它缺少你们系统里的三个关键特例。
第二步：人工补上 LLM 不知道的业务规则
class PaymentTransactionService(TransactionService):
"""在 LLM 骨架上叠加业务特例——这才是领域专家的价值"""
# 业务特例 1：退款必须冲正原交易，不能负数记账
def record_refund(self, refund_tx_id: str, original_tx_id: str,
amount: int, reason: str):
original = self.ledger_store.get_entries(original_tx_id)
if not original:
raise ValueError(f"Original transaction {original_tx_id} not found")
# 冲正：借贷方向翻转
reversed_entries = []
for entry in original:
reversed_side = (
EntrySide.CREDIT if entry.side == EntrySide.DEBIT
else EntrySide.DEBIT
)
reversed_entries.append(LedgerEntry(
account_id=entry.account_id,
side=reversed_side,
amount=amount, # 退款金额可能小于原交易（部分退款）
transaction_id=refund_tx_id,
description=f"REFUND of {original_tx_id}: {reason}",
))
self.ledger_store.atomic_write(reversed_entries)
return True
# 业务特例 2：跨日结算的挂账窗口（17:00 后的交易挂到次日）
def record_transaction(self, transaction_id: str,
debit_account: str, credit_account: str,
amount: int, description: str = "",
settlement_time: Optional[str] = None):
from datetime import datetime, time
now = datetime.utcnow()
cutoff = time(17, 0) # 你们银行的实际截止时间，文档里没写
if now.time() > cutoff and settlement_time is None:
# 挂账：先记入 suspense account，次日自动冲账
suspense_account = "SUSPENSE_CROSS_DAY"
self.record_transaction(
transaction_id + "_suspense",
debit_account, suspense_account, amount,
description=f"[SUSPENSE] {description}",
)
# 注册次日冲账任务（你们内部的调度系统）
self.scheduler.schedule_next_day_reconciliation(
suspense_tx_id=transaction_id + "_suspense",
target_tx_id=transaction_id,
credit_account=credit_account,
amount=amount,
)
return True
return super().record_transaction(
transaction_id, debit_account, credit_account,
amount, description,
)
# 业务特例 3：对账偏移量容忍（历史数据迁移导致的 ±50 分偏差）
def reconcile_with_bank(self, our_entries: list, bank_statement: list):
TOLERANCE = 50 # 2017 年数据迁移遗留的固定偏移，只有你知道
our_total = sum(e.amount for e in our_entries)
bank_total = sum(e.amount for e in bank_statement)
diff = abs(our_total - bank_total)
if diff == 0:
return {"status": "matched", "diff": 0}
elif diff <= TOLERANCE:
return {"status": "tolerated", "diff": diff,
"note": "within historical migration tolerance"}
else:
return {"status": "mismatch", "diff": diff}
这三段补丁代码才是十年经验的真正载体。LLM 能生成骨架，但跨日挂账窗口、退款冲正规则、对账偏移容忍——这些来自踩坑和与业务方反复沟通的知识，它无从得知。
新的护城河在哪里
如果"领域知识的稀缺性"不再是护城河，工程师需要重新锚定价值：
| 旧护城河 | 新护城河 |
|---|---|
| 记住 PCI DSS 的条文 | 能判断哪条条文在你们场景下真正有风险 |
| 能写对账逻辑 | 能发现银行接口的 undocumented 行为并设计兜底 |
| 知道双复式记账的规则 | 知道你们系统里哪些地方违反了规则且不能改 |
| 快速产出代码 | 快速判断 LLM 产出代码里哪些在你们场景下会炸 |
核心转变：从"知识的持有者"变成"知识的应用裁判"。你不再是最快写出代码的人，但你是最快判断代码在真实环境里能不能跑的人。
给自己做个审计清单
与其被动焦虑，不如主动盘点自己手里还有哪些 LLM 替代不了的筹码：
- ** undocumented 的系统行为**——你亲历过的那些文档没写但真实存在的坑，LLM 不知道。
- 跨团队的协商边界——和法务、合规、运营反复拉锯后形成的决策，不是代码能表达的。
- 历史数据的幽灵——2017 年那次迁移留下的偏移量，只有你和那几个老同事知道。
- 对"差不多"的判断力——LLM 会给出一个看起来合理的方案，但你能一眼看出它在你们场景下差了那关键的 5%。
如果这四条你都不剩了，那确实该焦虑。但大多数十年经验的工程师，至少还握着两条。问题是——你有没有把它们显性化，变成 LLM 也无法绕过的约束文档？
下一步建议：把你脑子里的那些 undocumented 规则写下来，变成代码里的注释、测试里的断言、架构决策记录（ADR）里的条目。这些才是 LLM 时代真正值钱的东西——不是你会写什么代码，而是你知道哪些代码在你们系统里不能写。