用 Kiro 构建行业专业软件：从需求到交付的地震多次波压制工具实践

摘要：本文记录了一次用 Kiro 开发行业垂直软件的完整实践:在 5天跨度内、纯编码约十余小时,构建出一套面向陆上叠前数据的地震多次波压制处理系统,交付约 2,408行代码与文档,涵盖预测反褶积、双曲 Radon 变换、SRME 三种经典算法,以及 CLI、桌面 GUI 与多炮并行流水线。文章以真实的 git记录和测试输出还原开发过程,并坦诚讨论了算法在小合成数据上的适用边界——预测反褶积接近论文最佳水平,而 Radon 与 SRME受方法本身限制效果有限,价值在于工程落地而非指标刷榜。在方法论层面,本文以同一项目为样本对比了 Spec 驱动与 Vibe Coding两种范式:算法内核以 Spec 固化统一接口规范,GUI 则以探索式迭代快速成型,并给出”内核用 Spec、外围用vibe、衔接靠接口”的分层结论。核心观点是:AI不会替你突破方法的物理边界,但能把”领域知识转化为可运行、可扩展代码”这一过程的成本显著拉低。

1. 引言

本文记录一次完整的行业垂直软件开发实践——用 Kiro 在 5 天跨度内、实际编码十余小时 构建一套陆上地震勘探多次波压制处理系统，最终交付约 2,408 行（Python 1,592 行 + 技术文档 693 行 + 脚本/配置 123 行）、3 个核心算法、完整 GUI + CLI + 并行流水线。本文分享 Kiro 在面对”陌生的、专业的、文档稀少的”行业领域时如何成为开发者的有效协作伙伴，也如实记录它的得力之处,以及来自处理方法本身的局限。

2. 行业专业软件的开发困境

地震勘探数据处理是石油天然气勘探的关键环节。地震波在地下强反射界面之间反复振荡，会产生多次波——一种严重干扰成像精度的相干噪声。多次波压制传统上依赖商业软件，它们价格昂贵、扩展困难，且对算法迭代不友好。

如果你是一名地球物理工程师，想自己实现一套验证算法用的处理工具，你会面临的问题包含以下几点：：

• 算法门槛高：预测反褶积、Radon 变换、SRME 等经典方法散落在 1957–2010 年的论文中
• 工业数据格式复杂：SEG-Y 格式有严格的二进制规范，道头字段众多
• 缺乏现成代码：开源生态远不如机器学习领域繁荣
• 工程化要求高：需要 GUI、需要支持大数据、需要文档

按传统经验，单人完成这样的项目通常需要 3–4 周——一周读论文；一周实现核心算法；一周做 GUI；一周联调测试。这次我用 5 天跨度 + 一个 Kiro Pro 订阅 完成了，期间真正花在这个项目上的编码时间只有十余小时。

3. 与 Kiro 的真实交互：从”专家设定”到需求锁定

我没有从写代码开始，而是先用四轮对话，把”实现一个多次波压制软件”这样的模糊愿望，逐步收敛成可执行的设计。下面是真实的交互记录（来自真实的交互过程，未做美化，只做了适当的精简）。

第 1 轮 · 给 Kiro 一个专家身份

我：你是一名专业的地球物理勘探专家，同时也擅长软件开发和算法理论研究，现在要做一个行业专业软件。通过几轮交互来了解需求，完成设计。

Kiro 没有急着写代码，而是反问了五个定位问题：面向哪个细分领域（地震/电法/重磁/测井/综合）？核心用途（采集控制/数据处理/正演模拟/成果解释/全流程）？目标用户（野外施工队/室内处理解释/科研院所）？是否有对标软件（Kiro给出了几个行业内知名软件的名称，实际名称本文中省略）？部署形态（桌面/Web/混合）？

这个”先设定专家身份、再让它主动澄清边界”的开场，是后面一切顺利的关键。

第 2 轮 · 反过来考它的领域知识

我：要做一个物探数据解释的前期处理准备功能，去除多次波。你知道地震勘探数据中多次波产生的原因吗？

Kiro 先完整讲清了多次波的成因、三类分类（自由表面 / 层间 / 短程）、典型场景与危害，然后才追问 5 个技术问题：针对哪类多次波、海上还是陆上、数据格式、叠前还是叠后、算法偏好。它对领域的掌握程度，到这一步我就放心了。

第 3 轮 · 锁定边界

我：三类都需要处理，先做一个陆上处理的，输入数据是 SEG-Y，处理阶段是叠前。先不考虑性能，采用一个小的数据做功能验证。

Kiro 据此给出了算法组合方案（预测反褶积 / Radon / SRME）、处理流程、可视化需求、技术栈建议和测试数据方案，并提出 5 个确认问题。

第 4 轮 · 定形态

我：先做成独立模块，可视化做简单的对比图，技术栈先做 Python 版本。我现在没有 SEG-Y 数据，需要一个合成数据生成模块来验证效果。

Kiro 输出了完整设计方案（项目结构、模块设计、算法细节、依赖、开发阶段），我确认无误。

这四轮对话被整理成 docs/requirements.md（45 行），其中的算法选型直接成为后续开发的依据：

这一阶段没有产出一行代码，却把模糊需求拆成了 5 个可执行、可验证的 Phase——投入产出比最高的一步。

4. 分阶段实现：每个 Phase 都有可运行产物

5 个 Phase 严格分离，每个阶段都有独立的验证脚本，结束时跑一遍、输出量化指标：

Phase 1: 合成数据 + SEG-Y IO + 可视化   	← 基础设施
Phase 2: 预测反褶积 + test_phase2.py    	← 算法 1
Phase 3: Radon 变换 + test_phase3.py    	← 算法 2
Phase 4: SRME + test_phase4.py          	← 算法 3
Phase 5: Pipeline + 主入口              	← 工程化

这种”先可见后优化”的节奏，让我可以随时校验 Kiro 的实现是否正确，而不是等全部写完再发现错误。下面挑几个真正体现协作价值的片段。

4.1 它先读论文，再动手

当我说”实现 SRME”时，Kiro 没有照公式硬写，而是先解释了 Verschuur 1992 年方法的核心思想——用数据自身的多次卷积预测多次波，再自适应相减——并主动提示：“单炮集 SRME 效果有限，理想情况需要补充零偏移距和负偏移距道。”这是行业常识，但很多 AI 助手会直接照公式硬套。它把方法的适用边界也一并告诉了我（这个边界，后面第 4 节会再次应验）。

4.2 公式到代码：主动向量化

地震处理的核心难点是公式到代码的翻译。以双曲 Radon 变换为例，论文里的正变换是：

直接用 Python 嵌套循环（速度 × tau × 道）性能极差。Kiro 主动给出了向量化实现（节选自 demultiple/radon_transform.py）：

def velocity_scan(data, dt, offsets, velocities):
    """速度扫描（双曲Radon正变换）— 向量化实现"""
    n_traces, n_samples = data.shape
    n_v = len(velocities)
    t0 = np.arange(n_samples) * dt
    panel = np.zeros((n_v, n_samples))
    off2 = offsets ** 2

    for iv, v in enumerate(velocities):
        # 广播构建二维走时矩阵 t_hyp[tr, it]
        t_hyp = np.sqrt(t0[np.newaxis, :] ** 2 + off2[:, np.newaxis] / v ** 2)
        isamp = t_hyp / dt
        i0 = isamp.astype(np.intp)
        frac = isamp - i0

        valid = (i0 >= 0) & (i0 < n_samples - 1) & (t0[np.newaxis, :] > 1e-6)
        i0_safe = np.clip(i0, 0, n_samples - 2)

        # 线性插值 + 沿道维度求和
        vals = np.where(valid,
                        (1 - frac) * data[np.arange(n_traces)[:, None], i0_safe] +
                        frac * data[np.arange(n_traces)[:, None], i0_safe + 1],
                        0.0)
        count = valid.sum(axis=0).astype(float)
        total = vals.sum(axis=0)
        panel[iv] = np.divide(total, count, out=np.zeros_like(total), where=count > 0)

    return panel

这段代码用 NumPy 广播替代了两层 Python 循环，并内置了线性插值、边界保护、零除保护——这些工程细节都是 Kiro 主动加的，无需我逐条要求。实测 48 道 × 1001 样点的炮集，速度扫描在 本地开发电脑上仅需约 0.18 秒，相比纯 Python 嵌套循环提速约 30 倍。

4.3 工程细节的本能

seisio/segy_io.py 里读取数据用了 segyio.tools.collect(f.trace[:]) 而非逐道循环，源码注释直接写着”批量读取，比逐道快 10x+“：

with segyio.open(filepath, ignore_geometry=True) as f:
    data = segyio.tools.collect(f.trace[:])  # 批量读取，比逐道快10x+

这种”很小但非常关键”的工程经验，Kiro 不需要被提醒。

4.4 统一接口，让后续扩展几乎零成本

到 Phase 5，三个算法模块已独立可用。Kiro 主动统一了模块接口——每个模块都暴露一个 process(data, dt, **params) -> (cleaned, removed)。基于这个约定，Pipeline 实现极简（102 行）：

pipe = Pipeline()
pipe.add_step("反褶积", predictive_deconv, {"prediction_lag_ms": 222.0})
pipe.add_step("Radon",  radon_transform,   {"v_primary_range": (1700, 5000)})
pipe.add_step("SRME",   srme,              {"window_len": 200})
result, history = pipe.run(data, dt)

后来扩展并行处理时，只新增了一个 run_parallel 方法，原有代码完全不变：

results = pipe.run_parallel(shots, dt, n_workers=cpu_count())

实测 8 炮 × 48 道数据，并行（8 进程）相比串行提速约 5.6 倍。这次性能优化对应 git 上 6a49330（2026-03-09）那次提交。

4.5 从 CLI 到 GUI

CLI 完成后，我提出”加一个 GUI 桌面版本”。Kiro 当晚就交付了初版，又连着迭代三轮——初版加三轮迭代的 4 次提交，全部落在当晚完成。

20:51  v1.1: 完成初版              
20:56  GUI: 添加导出对比图片按钮(PNG/JPG/PDF)        
21:08  GUI: 合成数据参数可调(道数/道间距/采样率…)    
21:35  GUI: 右侧改为 Tab 切换显示                   

最终 GUI 共 410 行：左侧控制面板（数据源/流程勾选/参数）、右侧 4 个 Tab（原始/处理后/去除分量/三图对比）、后台线程 + 进度条 + 日志、中文字体跨平台自适应、SEG-Y 加载与结果保存。GUI 的处理逻辑直接复用 Pipeline，没有任何重复代码——这正是 3.4 节那个统一接口埋下的伏笔。

关于代码质量：v1.0 之后的 6 次提交全部是功能增量与交互重构，git 历史中没有一次是为了回退逻辑错误。当然并非每行都一次成型——算法参数（预测步长、Radon 速度范围、SRME 窗长）经过了多轮调参才达到第 4 节的效果——但结构性 bug 确实很少，GUI 实现过程也没有卡在调试上。

5. 交付与效果：一次看清所有数字

所有数字都来自 git 提交记录、wc -l 源文件统计和 test_phase*.py 的实际运行输出，可在仓库中复现。

5.1 交付清单

seismic_demultiple/                     共约 2,408 行
├── synth/generator.py             168  # 合成数据正演
├── seisio/segy_io.py               54  # SEG-Y IO
├── demultiple/
│   ├── predictive_deconv.py       144  # 预测反褶积
│   ├── radon_transform.py         136  # Radon 变换
│   └── srme.py                    137  # SRME
├── viz/compare_plot.py             93  # 可视化
├── pipeline.py                    102  # 流程编排（含并行）
├── main.py                        133  # CLI 入口
├── gui.py                         410  # tkinter GUI
├── test_phase{2,3,4}.py           211  # 各阶段验证脚本
├── docs/(requirements/manual/paper) 693  # 需求/操作手册/技术论文
└── README + run.sh + 配置          123  # 项目文档与启动脚本

5.2 时间投入

整体跨度 5 天，纯编码十余小时——算法与性能优化是大头，GUI 当晚一气呵成。

git 提交记录（共 7 次）：

5ac91b6  2026-03-06 16:29  v1.0: 地震多次波压制软件初始版本
8fcb779  2026-03-06 20:51  v1.1: 添加tkinter GUI桌面应用
d4df2ab  2026-03-06 20:56  GUI: 添加导出对比图片按钮(PNG/JPG/PDF)
eaf2986  2026-03-06 21:08  GUI: 合成数据参数可调(道数/道间距/采样率/记录长度/主频/噪声)
c14808d  2026-03-06 21:35  GUI: 右侧改为Tab切换显示(原始/处理后/去除分量/三图对比)
ff01a2d  2026-03-06 22:03  移除data/大文件，添加到.gitignore
6a49330  2026-03-09 20:17  perf: 大文件处理性能优化

5.3 算法效果

先看合成数据本身——含多次波与纯一次波的对比，这是后续所有定量评估的基准：

合成数据：含多次波 vs 纯一次波

预测反褶积处理前后（短程多次波压制效果最明显）：

预测反褶积前后对比

三种方法串联的全流程结果：

全流程处理结果

定量指标（来自 test_phase*.py 输出）：

需要说明的一点：预测反褶积接近论文报告的最佳水平，但 Radon 和 SRME 的相关系数明显偏低。这不是实现 bug，而是方法适用边界使然——

• 本项目需求锁定为陆上叠前数据，而 SRME 本质上是为海洋自由表面多次波设计的数据驱动方法；在陆上 + 单炮合成数据条件下（缺少近偏移距/负偏移距道），SRME 的预测精度天然受限，这与 3.1 节 Kiro 一开始就提示的边界完全吻合。
• Radon 的速度可分离性同样依赖足够的偏移距孔径，单炮 48 道的合成数据偏小。

换句话说，这套工具的真正价值在于”几天内把三类经典算法落地成可运行、可量化、可扩展的工程”，而不是在小合成数据上刷算法指标数字。

5.4 资源消耗

整个项目在一个 Kiro Pro 订阅下完成，未触及配额上限。由于同期并行其他项目，无法精确分摊到本项目的 credit 消耗，这里只给定性结论：单次会话基本能在 1–3 小时内完成一个 Phase，长文档生成（论文、手册）和算法调参是消耗大头，整体处于 Pro 月度配额的轻松区间。做类似规模的项目，Pro 订阅完全够用。

6. 投入产出对比

最让我意外的副产品是一份 381 行的技术论文（docs/paper.md），结构完整：摘要、引言、方法原理（含公式）、软件设计、合成数据实验、定量评估、讨论、结论、10 篇参考文献，且所有指标都从测试脚本输出中提取，不是编造。

7. Spec 与 Vibe Coding：两种范式的适用边界与协同

随着 AI 辅助编程的成熟，实践中逐渐形成两种工作范式。本项目在不同层次上分别采用了二者，可作为一组对照样本。

7.1 两种范式的定义

• Spec 驱动（规格优先）：在编码前先通过多轮交互明确需求、边界条件、模块接口与验收标准，形成可追溯的规格，再分阶段实现。本项目主线即如此：4 轮需求交互 → requirements.md（45 行）→ 5 个 Phase → 统一的 process() 接口规范。
• Vibe Coding（探索式迭代）：不预先定义规格，以自然语言描述目标意图，由模型生成初版后，基于可见结果持续修正。本项目的 GUI 即采用此方式。

二者的本质差异在于消化不确定性的时机：Spec 把不确定性放在编码前、用规格解决；Vibe Coding 把不确定性放在编码后、用迭代解决。

7.2 同一项目内的对照

在同一开发者、同一工具链下，本项目内核采用 Spec、GUI 采用 Vibe Coding，可直接横向比较：

二者并非互相替代，而是各自适用于不同的开发场景。

7.3 关键在于二者的衔接

本项目最具参考价值的一点是：GUI 能够在几十分钟、零重复代码完成，前提是算法层已通过 Spec 固化了统一的 process(data, dt, **params) 接口规范，GUI 仅在其上复用。

这说明 Vibe Coding 的高效并非源于省略设计，而是建立在已有的良好接口设计之上。缺少这层经 Spec 沉淀的接口基础，同样的探索式迭代往往产出高耦合、难维护的代码——短期的速度收益最终会以维护成本偿还。

7.4 分层策略

因此，结论并非二选一，而是按层次分别采用：

• 内核采用 Spec：算法、数据格式、模块接口与对外行为等会被反复依赖的部分，正确性与稳定性优先，应在前期明确规格。
• 外围采用 Vibe Coding：界面、可视化、交互细节与一次性脚本等需借助可见原型澄清需求的部分，快速迭代的收益高于前期规划。
• 以接口为边界衔接：让探索式迭代的部分建立在 Spec 定义的稳定接口之上，兼顾迭代速度与可维护性。

一个可操作的判别标准：该模块是否会被其他部分依赖、是否需要复用？ 是，则先行 Spec；否（纯探索性工作），可直接采用 Vibe Coding。

8. 经验总结：用 Kiro 开发行业软件的几条建议

1. 先给身份，再谈需求。开场那句”你是一名地球物理勘探专家，同时擅长软件开发”，让 Kiro 用专家视角主动澄清边界，比直接丢需求高效得多。
2. 内核从 Spec 开始，外围放手 vibe。算法、数据格式、接口这类会被反复依赖的部分，先谈清规范（4 轮交互产出 45 行需求文档，避免了后续大量返工）；界面、交互这类探索性部分则大胆迭代——分层用力，别一刀切。
3. 分阶段验证胜过整体提交。每个 Phase 都要有可运行的测试脚本和量化指标，让产出可被持续校验。
4. 先定义统一接口，再写实现。process(data, dt, **params) 这个简单约定，让后期加 GUI、加并行几乎零成本。
5. 让 Kiro 同步写文档。论文、需求记录、操作手册随开发同步生成，比事后补写质量高得多。
6. 尊重方法的适用边界。Kiro 会主动告诉你某个方法的局限（如陆上单炮 SRME 效果有限），别把它的诚实当保守——那恰恰是领域 know-how。

➡️ 下一步行动：

相关文章：

• 用 Kiro Skill 打造你的专属 AI 工作流：以会议纪要自动生成为例
• AI 驱动的 Graviton 迁移评估：Kiro Power 实战指南
• 当 Kiro 遇上 OpenClaw：AI Agent 双向协作的实践探索
• 用 Kiro CLI 自动搭建 FluentBit 日志采集方案：两种 EKS 埋点数据落地 S3 Parquet 的实战对比
• 以Kiro快速部署云上Agent：只需几个小时，从业务需求到部署于Amazon Bedrock Agentcore落地

9. 结语

行业专业软件的开发瓶颈，往往不是编程能力，而是”领域知识 + 工程经验 + 可持续维护”三者的同时缺失。这次实践给出了一个量化对比：5 天跨度对比 3 周，最终交付物可直接用于算法验证，并自带可发表级别的技术论文。

需要清醒的是：Kiro 不会替你突破方法本身的物理边界（陆上单炮 SRME 该弱还是弱），但它能把”领域知识转化为可运行、可扩展代码”这个过程的成本，拉到一个新的低点。如果你正困在”自己写太慢、买商业软件太贵”的两难里，不妨试试用 Kiro ，用 Kiro使用自然语言开发行业专业软件的新范式。

本项目代码已上传github(https://github.com/nwcd-samples/seismic-demultiple)，欢迎地球物理同行交流改进。

10. 数据来源说明

• 代码行数：wc -l 统计项目所有源文件
• 时间数据：来自 git 提交时间戳
• 交互记录：来自项目中与Kiro交互记录的指令/反馈
• 算法效果：来自 test_phase*.py 的 stdout 输出，可在仓库中复现
• 性能数据：来自实测
• 资源消耗：定性描述，因同期并行多个项目，未进行精确分摊，完整项目消耗处于Kiro Pro 月度配额内

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用