1
00:00:00,000 --> 00:00:06,480
Here we go. Now we're going to do the feature dev, feature dev, feature dev,
开始了。现在我们要做功能开发，功能开发，功能开发，

2
00:00:06,480 --> 00:00:14,560
you can just put down and tab and then I'm going to say implement Jira ticket PL4
你只需放下并按 Tab 键，然后我会说实施 Jira Ticket PL4

3
00:00:16,479 --> 00:00:28,479
and make a PL. That's it. That's all we're doing. Off it goes. It's connected to Atlassian,
并制作 PL。就是这样。这就是我们正在做的一切。关了就走了。它与 Atlassian 连接，

4
00:00:28,479 --> 00:00:34,560
it's pulling PL4 and things are happening. I will see you back here in a minute. I know I'm
它正在拉 PL4，事情正在发生。我一会儿就回来见你。我知道我是

5
00:00:34,560 --> 00:00:39,759
going to be amazed and shocked. Let's see what happens. Okay. It's come back and asked me
会感到惊讶和震惊。让我们看看会发生什么。好的。它回来问我

6
00:00:39,759 --> 00:00:45,599
questions like before. The first one it's saying is for this V1 foundational ticket,
像以前一样的问题。第一个是针对这张 V1 基础票的，

7
00:00:45,599 --> 00:00:51,200
should authentication be functional or just have placeholder routes? And it should be placeholder
身份验证应该起作用还是仅具有占位符路由？它应该是占位符

8
00:00:51,200 --> 00:00:55,200
only, which I thought we were clear about in the ticket, but maybe not enough. So I'm going to
只是，我认为我们在票证中已经清楚地说明了这一点，但可能还不够。所以我要去

9
00:00:55,200 --> 00:01:00,000
move to placeholder only. That's that question. For the front-end back-end integration, should
仅移至占位符。这就是那个问题。对于前端后端集成，应该

10
00:01:00,000 --> 00:01:04,400
the current NDA form functionality remain client-side or should the form data be saved
当前的 NDA 表单功能保留在客户端，还是应该保存表单数据

11
00:01:04,400 --> 00:01:09,839
persisted to the back-end? Let's keep it client-side. And that's it. That's the end of
坚持到后端？让我们将其保留在客户端。就是这样。就这样结束了

12
00:01:09,839 --> 00:01:16,559
our questions. Off it goes. Back to thinking. Okay. It's now following the steps more precisely.
我们的问题。关了就走了。回到思考。好的。现在它正在更精确地遵循这些步骤。

13
00:01:16,559 --> 00:01:20,639
It's got to the architecture design and it's asking me to review this. If you look at the
它涉及到架构设计，并要求我对此进行审查。如果你看一下

14
00:01:20,639 --> 00:01:24,080
bottom here, it says, does this architecture approach look good to proceed with the
这里的底部，它说，这种架构方法看起来是否适合继续

15
00:01:24,080 --> 00:01:30,319
implementation? So let's have a look at it. Let me see. I have a clearer sense. Here we go.
执行？那么让我们来看看吧。让我看看。我有了更清晰的感觉。开始了。

16
00:01:30,319 --> 00:01:36,239
Static front-end fast API. That's good. Front-end Next.js static. That's fine. Fast API with UV.
静态前端快速API。那挺好的。前端 Next.js 静态。没关系。带 UV 的快速 API。

17
00:01:36,239 --> 00:01:40,879
SQLite for future use. Yes. Placeholder is only. Yes. Single container multistage build. Yes. That's
SQLite 供将来使用。是的。仅占位符。是的。单容器多阶段构建。是的。那是

18
00:01:40,879 --> 00:01:46,160
what I like. This all looks good. Pyproject.toml. I'm pleased to see that's what it didn't do before
我喜欢什么。这一切看起来都不错。 Pyproject.toml。我很高兴看到这是以前没有做过的

19
00:01:46,160 --> 00:01:52,000
that I didn't like. This seems sensible. That's sensible. This is a good structure.
我不喜欢。这似乎是明智的。这是明智的。这是一个很好的结构。

20
00:01:52,000 --> 00:01:56,800
Oh, I hope that that's not going to be. Oh, yeah. It's got roots. Okay. Yeah. Yeah. I like that.
哦，我希望那不会是这样。哦，是的。它有根了。好的。是的。是的。我喜欢这样。

21
00:01:56,800 --> 00:02:06,559
I like that. Docker compose is good. Fine. And this is all makes sense to me. I think this is good.
我喜欢这样。 Docker compose 很好。美好的。这对我来说都是有意义的。我认为这很好。

22
00:02:06,559 --> 00:02:13,600
Add the database to gitignore. That's very sensible. Okay. I think this is good.
将数据库添加到 gitignore。这是非常明智的。好的。我认为这很好。

23
00:02:13,600 --> 00:02:19,520
That all looks very sensible. Now, of course, if you are not familiar with these technical
这一切看起来非常明智。当然，如果您不熟悉这些技术

24
00:02:19,520 --> 00:02:24,720
decisions, then that's good because it's got a chat with me. Chat about this thing where you can
决定，那很好，因为它与我聊天。可以的地方聊聊这件事

25
00:02:24,720 --> 00:02:30,080
ask questions. Probe. This is where even if you're not from a technical background, you need to be the
提出问题。探测。即使您不是技术背景，您也需要成为

26
00:02:30,080 --> 00:02:35,600
boss. Be like the inquisitive manager that asks some probing questions to make absolutely sure
老板。就像好奇的经理一样，提出一些探究性的问题以确保万无一失

27
00:02:35,600 --> 00:02:40,320
you understand the different decisions because this is your opportunity to challenge. And, you
您理解不同的决定，因为这是您挑战的机会。你呢

28
00:02:40,320 --> 00:02:46,000
know, increasingly, it's getting better and better. It's hard to find fault in this. But had it done
知道，越来越好。这很难挑出毛病。但如果做到了

29
00:02:46,000 --> 00:02:52,240
this before in our prior project, PM, I would have noticed that it had a monolithic main.py
在我们之前的项目中，PM，我会注意到它有一个整体的 main.py

30
00:02:52,240 --> 00:02:56,639
and other problems with it that I would have seen ahead of time. But it's not making that mistake
以及我提前看到的其他问题。但它并没有犯这样的错误

31
00:02:56,639 --> 00:03:02,880
now, perhaps because it's been guided through this process. Okay. So I'm pressing one. Yes, proceed.
现在，也许是因为它已经完成了这个过程。好的。所以我就按一个。是的，继续。

32
00:03:02,880 --> 00:03:08,080
And off it goes. Well, that's incredible. It says that it's done everything. It says that it's
然后它就消失了。嗯，这太不可思议了。它说它已经完成了一切。它说它是

33
00:03:08,080 --> 00:03:15,199
tested it. All 76 tests pass, it says. And the API endpoints are done and that it's completed
测试了一下。它说，76 项测试全部通过。 API 端点已经完成并且已经完成

34
00:03:15,199 --> 00:03:21,440
everything and it's made a PR. And so I guess we should now test it ourselves and then we can move
一切都已成为公关。所以我想我们现在应该自己测试一下然后我们就可以移动

35
00:03:21,440 --> 00:03:27,919
on to the next. If we believe it, let's find out. We've got ourselves again a script that we should
继续下一步。如果我们相信的话，让我们来看看吧。我们又得到了一个我们应该的剧本

36
00:03:27,919 --> 00:03:33,679
be able to run. We're going to do that now. So I bring up a new terminal window. Here we go. I'm
能够运行。我们现在就这么做。所以我打开了一个新的终端窗口。开始了。我是

37
00:03:33,679 --> 00:03:43,919
going to do scripts slash start dash Mac dot shell. Okay, it's building something. It's done.
执行脚本 斜线开始 破折号 Mac 点 shell。好的，它正在构建一些东西。完成了。

38
00:03:43,919 --> 00:03:51,279
It started it. It says right here. Let's open this up. Here we go. Click on here. Up it comes. It
它开始了。它说就在这里。让我们打开这个。开始了。点击这里。它来了。它

39
00:03:51,279 --> 00:03:57,839
looks the same, but we know it's running through this this bigger infrastructure now. And I guess
看起来一样，但我们知道它现在正在通过这个更大的基础设施运行。我猜

40
00:03:57,839 --> 00:04:01,919
we could just just quickly check that if we do New York that it appears over on the right, it does
我们可以快速检查一下，如果我们检查纽约，它会出现在右侧，它确实会出现

41
00:04:01,919 --> 00:04:06,559
seem to. And what about the downloading? Is it still going to work? Yep, that still seems to work.
似乎是。那么下载呢？它还可以工作吗？是的，这似乎仍然有效。

42
00:04:07,440 --> 00:04:13,520
Here we go. Here are my downloads. Recent download. And there it is. Fine. It's all working.
开始了。这是我的下载。最近下载。就是这样。美好的。一切正常。

43
00:04:13,520 --> 00:04:20,160
It's that's great. On a different route on local hosted 8000. It's coming through just great.
真是太好了。在本地托管 8000 上的另一条路线上。效果非常好。

44
00:04:20,160 --> 00:04:28,000
Amazing. Okay, so back we come here. And yeah, we can we can see that the tons and tons of stuff
惊人的。好吧，那我们就回到这里吧。是的，我们可以看到大量的东西

45
00:04:28,000 --> 00:04:36,399
has been built for good back end and routes and lots of things here. Okay, so now I'm going to say,
已经为良好的后端和路线以及这里的很多东西而构建。好吧，现在我要说的是，

46
00:04:37,679 --> 00:04:51,040
please merge the PR locally and push push to main and switch branch to main.
请在本地合并PR并将push到main并切换分支到main。

47
00:04:51,519 --> 00:04:52,559
Let's make that happen.
让我们实现这一目标。

48
00:04:56,799 --> 00:05:02,720
And then at the end of this, off it goes, it's doing all of its things. And what are we gonna
然后在最后，一切都结束了，它正在做所有的事情。我们要做什么

49
00:05:02,720 --> 00:05:09,600
do next? We're just going to go push ahead and do do PL five, the next of our actions. So this is,
接下来做什么？我们将继续推进并执行 PL 5，这是我们的下一个行动。所以这是，

50
00:05:09,600 --> 00:05:15,040
of course, a bigger one, I'm just going to go up here, feature dev implement JIRA ticket PL five
当然，更大的，我只是要在这里，功能开发实现 JIRA 票证 PL 5

51
00:05:15,040 --> 00:05:22,000
and make a PR. Maybe maybe before we do this, not so fast, not so fast. Let's look at context.
并制作公关。也许在我们这样做之前，不要那么快，不要那么快。让我们看看上下文。

52
00:05:22,000 --> 00:05:28,000
Always look at the context. Let's take a look. How are we doing here? Scroll up. Look at that.
始终查看上下文。我们来看一下。我们在这里怎么样？向上滚动。看看那个。

53
00:05:28,000 --> 00:05:33,519
It is pretty full. Why don't we do something a bit different? Why don't we say, please
这是相当完整的。我们为什么不做一些不同的事情呢？为什么我们不说，请

54
00:05:33,519 --> 00:05:46,559
update, add, add, add some concise details to the end of claude.md with an update on what has been implemented.
更新，添加，添加，在 claude.md 末尾添加一些简洁的细节，并更新已实现的内容。

55
00:05:51,359 --> 00:05:56,880
And change anything else that we've done here.
并改变我们在这里所做的任何其他事情。

56
00:05:56,880 --> 00:06:06,079
And change anything that's no longer accurate
并更改任何不再准确的内容

57
00:06:08,880 --> 00:06:13,040
in claude.md because I remember there's a section at the top when we say this is what we've got.
在 claude.md 中，因为我记得顶部有一个部分，我们说这就是我们所拥有的。

58
00:06:14,239 --> 00:06:19,920
Okay, so we'll let it do that because we're going to want to now reset it to do the next one.
好的，所以我们让它这样做，因为我们现在要重置它以执行下一个操作。

59
00:06:19,920 --> 00:06:24,079
And this is a good practice because if we just leave it going, it's going to fill up the rest
这是一个很好的做法，因为如果我们让它继续下去，它就会填满剩下的部分

60
00:06:24,079 --> 00:06:29,600
of the context. Then it's going to do a compact. And as it does that compact, it's always a bit
的上下文。然后它会做一个紧凑的。当它如此紧凑时，它总是有点

61
00:06:29,600 --> 00:06:34,880
risky. What you tend to find is that it selectively forgets some of the things that did really matter
有风险。你往往会发现它有选择性地忘记了一些真正重要的事情

62
00:06:34,880 --> 00:06:41,119
from things like claude.md in its attempt to squash everything down. So people are afraid
来自 claude.md 等试图压制一切的东西。所以人们害怕

63
00:06:41,119 --> 00:06:45,519
of compacting for good reason. You get used to this kind of fear of the compact once you've done
压缩是有充分理由的。一旦你完成了，你就会习惯这种对紧凑型的恐惧

64
00:06:45,519 --> 00:06:49,679
this for a while because performance tends to degrade after it. All right, now we've done that,
这种情况会持续一段时间，因为此后性能往往会下降。好吧，现在我们已经做到了，

65
00:06:49,679 --> 00:06:54,399
let's go and have a look at claude.md. Let's see what we've got here. Open preview.
让我们去看看claude.md。让我们看看这里有什么。打开预览。

66
00:06:55,920 --> 00:07:00,399
And this is a SAS product, the current implementation supports it. Okay, with no
这是一个SAS产品，当前的实现支持它。好吧，没有

67
00:07:00,399 --> 00:07:05,040
development progress, that's all good. AI design, it hasn't messed this up. It still says use your
发展进步，这一切都很好。人工智能设计，它并没有搞砸这一点。它仍然说使用你的

68
00:07:05,040 --> 00:07:14,000
skill, color scheme, implemented status. Okay, good, good, good, good. All right, fabulous.
技能、配色方案、实施状态。好的，好，好，好，好。好吧，太棒了。

69
00:07:14,000 --> 00:07:20,640
Now, now we can start again with Claude Code. We can clear the context with clear conscience,
现在，现在我们可以重新开始克劳德代码了。我们可以问心无愧地弄清楚背景，

70
00:07:20,640 --> 00:07:26,559
and then get on with the next one. So we will get on with that. So I'm going to do slash clear.
然后继续下一个。所以我们会继续下去。所以我要清除斜线。

71
00:07:27,920 --> 00:07:33,600
There we go. No content, it's all gone. Context, let's have a look at it. Nice and fresh.
我们开始吧。没有内容了，全部消失了。上下文，我们来看看。又漂亮又新鲜。

72
00:07:34,799 --> 00:07:40,640
It's of course still got that memory in there. You can see that the memory file is 1.8k tokens.
当然，那段记忆仍然存在。可以看到内存文件有1.8k个token。

73
00:07:40,640 --> 00:07:45,040
It's got a little bit in there. So we've got some stuff in there. Now, if I go up,
里面有一点点。所以我们里面有一些东西。现在，如果我上去，

74
00:07:45,760 --> 00:07:53,359
up, up, here we go. Implement JIRA ticket PL5 and make a PR. But we may need to reauthenticate.
起来，起来，我们开始吧。实施 JIRA 票证 PL5 并制作 PR。但我们可能需要重新验证。

75
00:07:53,359 --> 00:07:57,359
Should we just give it a try? Let's see what happens. If it's able to read JIRA or whether
我们应该尝试一下吗？让我们看看会发生什么。是否能够读取 JIRA 或者是否

76
00:07:57,359 --> 00:08:08,559
it's going to get stuck. It's, let me see, we'll do this. I think this is a good sign.
它会被卡住。让我想想，我们会这样做。我认为这是一个好兆头。

77
00:08:08,559 --> 00:08:13,519
This is what happens when it gets stuck. It just stays like this. When this happens, it means it
这就是当它被卡住时会发生的情况。它就这样。当这种情况发生时，就意味着

78
00:08:13,519 --> 00:08:18,320
needs me to reauthenticate. So if this happens to you, that's what's going on. I know this from
需要我重新验证。因此，如果这种情况发生在您身上，那就是正在发生的事情。我从

79
00:08:18,320 --> 00:08:24,000
bitter personal experience. So you press escape to interrupt like that. And now we've interrupted,
痛苦的个人经历。所以你按escape键就可以打断。现在我们打断了，

80
00:08:24,000 --> 00:08:31,040
we do slash MCP and we come into our MCP service. We go into Atlassian. We're going to reauthenticate.
我们大幅削减 MCP，并开始提供 MCP 服务。我们进入 Atlassian。我们将重新进行身份验证。

81
00:08:31,839 --> 00:08:41,039
Up comes this approve and back down here. Accept. That is now done. Return to Cloud Code. Back we go.
上来了这个批准并回到这里。接受。现在已经完成了。返回云代码。我们回去吧。

82
00:08:41,039 --> 00:08:46,159
You see, I'm pretty quick at this now. Here we go. Try again. Now I think we'll find it. We'll
你看，我现在在这方面很快。开始了。再试一次。现在我想我们会找到它的。出色地

83
00:08:46,159 --> 00:08:51,520
be able to do it quite fast. Running and it's off. There we go. Okay. I'll see you in a second.
能够相当快地完成。运行起来就关掉了。我们开始吧。好的。我一会儿见。

84
00:08:51,520 --> 00:08:56,080
Okay. So it's asking me questions and they are really great questions. And these are the kinds
好的。所以它向我提出了一些问题，而且这些问题都非常好。还有这些种类

85
00:08:56,080 --> 00:08:59,919
of questions that you might go back and ask your business sponsor or product person if you were
如果您是这样的话，您可能会回去询问您的业务赞助商或产品人员

86
00:08:59,919 --> 00:09:06,719
trying to code this. Should the chat UI completely replace the form or coexist with it so your user
试图对此进行编码。聊天 UI 是否应该完全取代表单或与之共存，以便您的用户

87
00:09:06,719 --> 00:09:11,840
can switch between the chat and the form view? I think number one, replace the form entirely. We
可以在聊天和表单视图之间切换吗？我认为第一，完全取代表格。我们

88
00:09:11,840 --> 00:09:17,520
want a chat UI. That is the new way of doing things. So it's just going to be number one.
想要一个聊天界面。这就是新的做事方式。所以它只会成为第一。

89
00:09:17,520 --> 00:09:24,320
That is it. One. Should the document preview live updates or only after the user live updates? For
就是这样。一。文档应该预览实时更新还是仅在用户实时更新后预览？为了

90
00:09:24,320 --> 00:09:29,840
sure. Number one. How should the AI conversation begin? AI greets and asks first question.
当然。第一。人工智能对话应该如何开始？ AI 打招呼并提出第一个问题。

91
00:09:30,960 --> 00:09:38,080
Yes. Let's do that. When all the required fields are filled in, what should happen?
是的。让我们这样做吧。当所有必填字段都填写完毕后，会发生什么？

92
00:09:38,080 --> 00:09:46,479
AI confirms and show download. That sounds right. Yes. One. Okay. Submit answers. Great questions.
AI确认并显示下载。听起来不错。是的。一。好的。提交答案。很好的问题。

93
00:09:46,479 --> 00:09:52,400
Really good questions. They are like the sorts of things that one would ask typically. So yeah,
确实是好问题。它们就像人们通常会问的那样。所以是的，

94
00:09:52,640 --> 00:09:58,799
this process, this anthropic built process to guide you through really does seem to work.
这个过程，这个人为构建的过程来指导你完成似乎确实有效。

95
00:09:58,799 --> 00:10:02,640
Next up is going to be the architecture design and it'll ask me some architecture questions.
接下来是架构设计，它会问我一些架构问题。

96
00:10:02,640 --> 00:10:07,440
Okay. It's responded with the architecture setup. Let's have a look at what it's saying.
好的。它通过架构设置进行响应。我们来看看它说了什么。

97
00:10:07,440 --> 00:10:13,599
So it is saying, before designing the architecture, I have a few questions about the implementation.
也就是说，在设计架构之前，我有一些关于实现的问题。

98
00:10:13,599 --> 00:10:18,000
Sorry, here we go. Phase four. Let me launch this. All three architecture approaches are
抱歉，我们开始吧。第四阶段。让我启动这个。所有三种架构方法都是

99
00:10:18,000 --> 00:10:23,599
complete. So it launched three different agents. Minimal, clean, and pragmatic. Minimal changes.
完全的。因此它推出了三种不同的代理。简约、干净、务实。最小的变化。

100
00:10:23,599 --> 00:10:30,479
Replace NDA form with chat interface. Reuse everything else. Stateless backend. Sure. Okay.
用聊天界面替换 NDA 表格。重复使用其他所有东西。无状态后端。当然。好的。

101
00:10:30,479 --> 00:10:35,200
Clean architecture. Full session management. Database persistence. SSE. No, we don't want that.
干净的架构。完整的会话管理。数据库持久性。上交所。不，我们不想要这样。

102
00:10:35,200 --> 00:10:40,799
Definitely not. Pragmatic balance. Streaming responses. Parallel field extraction. Stateless
绝对不是。务实平衡。流式响应。平行场提取。无国籍

103
00:10:40,799 --> 00:10:47,359
backend. Clean. Blah, blah, blah. Two. Parallel. One for structured feature. Good UX. Simple to
后端。干净的。巴拉，巴拉，巴拉。二。平行线。一种用于结构化特征。良好的用户体验。简单到

104
00:10:47,359 --> 00:10:58,640
implement. Let me see. That's a difficult one. I don't particularly think we need streaming
实施。让我看看。这是一件困难的事情。我并不特别认为我们需要流媒体

105
00:10:58,640 --> 00:11:03,679
because we're using Cerebras, which is so fast that streaming is not going to be required.
因为我们使用的是 Cerebras，它的速度非常快，因此不需要流式传输。

106
00:11:03,679 --> 00:11:12,159
And I'd rather we just have the structured extraction. I think I'm going to go for the
我宁愿我们只进行结构化提取。我想我会去

107
00:11:12,159 --> 00:11:21,599
minimal one. I'm going to go here for two. It's going to let me chat about it. Yeah. I guess I'm
最小的一个。我要去这里两个人。它会让我聊聊它。是的。我想我是

108
00:11:21,599 --> 00:11:34,320
going to chat about this. Say chat about this. Okay. Okay. So would you like to clarify? I'd
要去聊聊这个。聊聊这个吧。好的。好的。那么你想澄清一下吗？ ID

109
00:11:34,960 --> 00:11:41,840
like the simple backend, the pragmatic choice,
喜欢简单的后端，务实的选择，

110
00:11:44,320 --> 00:11:56,960
except I only want one LLM call and no streaming because Cerebras is so fast that streaming isn't
除了我只想要一次 LLM 通话并且不需要流媒体，因为 Cerebras 太快了，流媒体不是

111
00:11:56,960 --> 00:12:08,799
necessary. One LLM call with structured outputs, including the response, is cleaner.
必要的。一次具有结构化输出（包括回复）的法学硕士通话更加清晰。

112
00:12:10,400 --> 00:12:15,520
There we go. That's what we're going with. So it's a conversation. Let's see what it's thinking.
我们开始吧。这就是我们要做的。所以这是一次对话。我们来看看它在想什么。

113
00:12:15,520 --> 00:12:21,280
It's thinking about that. Let's see what it likes about that. And hopefully it will build
它正在考虑这个问题。让我们看看它喜欢什么。希望它能够建成

114
00:12:21,280 --> 00:12:25,520
this. But this is the kind of thing that makes sense. Cerebras is extremely fast and a single
这。但这是有道理的事情。 Cerebras 速度极快且单一

115
00:12:25,520 --> 00:12:31,280
structure output call returns both the response text and the extra fields is cleaner. Let me
结构输出调用返回响应文本，并且额外的字段更清晰。让我

116
00:12:31,280 --> 00:12:36,159
update the approach. Great. So I like that interaction. I like the fact that it made me
更新方法。伟大的。所以我喜欢这种互动。我喜欢它让我

117
00:12:36,159 --> 00:12:44,080
think. You could see my cogwheels were turning there. And it was a decent question. It was a
思考。你可以看到我的齿轮在那里转动。这是一个很好的问题。这是一个

118
00:12:44,080 --> 00:12:48,400
good debate. I could see why it would think that streaming would be a better experience. But I do
很好的辩论。我可以理解为什么它会认为流媒体会是更好的体验。但我愿意

119
00:12:48,400 --> 00:12:52,400
think from my knowledge of Cerebras, it's so fast that it would just be like zipping through. It
根据我对 Cerebras 的了解，它的速度太快了，就像快速穿过一样。它

120
00:12:52,400 --> 00:12:59,119
wouldn't be necessary. And it would be extra complexity for little benefit. So I'd rather
没有必要。而且这会增加额外的复杂性，但收效甚微。所以我宁愿

121
00:12:59,119 --> 00:13:03,359
stick with simpler there. Okay. It's going on to implementation. I will see you in a second
坚持使用更简单的方法。好的。正在实施中。我很快就会见到你

122
00:13:03,359 --> 00:13:04,960
when implementation is complete.
当实施完成时。